perm filename COMMON.4[COM,LSP] blob
sn#820694 filedate 1986-07-12 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00642 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00079 00002
C00080 00003 ∂28-Jul-83 1912 FAHLMAN@CMU-CS-C.ARPA ERROR SIGNALLING FUNCTIONS
C00083 00004 ∂28-Jul-83 2130 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Non-evaluated error message in ASSERT
C00085 00005 ∂28-Jul-83 2155 WHOLEY@CMU-CS-C.ARPA Non-evaluated error message in ASSERT
C00087 00006 ∂29-Jul-83 0607 GBROWN@DEC-MARLBORO.ARPA ERROR SIGNALLING FUNCTIONS
C00090 00007 ∂29-Jul-83 0807 FAHLMAN@CMU-CS-C.ARPA Non-evaluated error message in ASSERT
C00093 00008 ∂29-Jul-83 1338 @MIT-MC:MOON%SCRC-TENEX%MIT-MC@SU-DSN Non-evaluated error message in ASSERT
C00095 00009 ∂29-Jul-83 2131 Guy.Steele@CMU-CS-A ASSERT and CHECK-TYPE
C00096 00010 ∂05-Aug-83 1309 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX File open options
C00099 00011 ∂09-Aug-83 0809 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX File opening, :TRUNCATE
C00101 00012 ∂14-Aug-83 1216 FAHLMAN@CMU-CS-C.ARPA Things to do
C00110 00013 ∂15-Aug-83 1251 @MIT-MC:BENSON@SPA-NIMBUS Looping constructs
C00113 00014 ∂15-Aug-83 2305 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Things to do
C00117 00015 ∂15-Aug-83 2342 FAHLMAN@CMU-CS-C.ARPA Things to do
C00119 00016 ∂16-Aug-83 0038 @MIT-MC:Cassels@SCRC-TENEX Things to do
C00121 00017 ∂16-Aug-83 2131 @MIT-MC:HIC@SCRC-TENEX Things to do
C00124 00018 ∂16-Aug-83 2324 HEDRICK@RUTGERS.ARPA Re: Things to do
C00126 00019 ∂17-Aug-83 0848 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: Things to do
C00128 00020 ∂18-Aug-83 1006 @MIT-MC:benson@SCRC-TENEX What to do next
C00137 00021 ∂18-Aug-83 1134 @MIT-MC:MOON@SCRC-TENEX subsetting
C00139 00022 ∂18-Aug-83 1226 HEDRICK@RUTGERS.ARPA Re: subsetting
C00140 00023 ∂18-Aug-83 1224 HEDRICK@RUTGERS.ARPA Re: What to do next
C00144 00024 ∂18-Aug-83 1221 FAHLMAN@CMU-CS-C.ARPA What to do next
C00160 00025 ∂18-Aug-83 1349 @MIT-MC:MOON@SCRC-TENEX subsetting
C00161 00026 ∂18-Aug-83 1352 @MIT-MC:benson@SCRC-TENEX What to do next
C00170 00027 ∂17-Sep-83 1809 GSB@MIT-ML implied contracts in the mapping functions?
C00173 00028 ∂17-Sep-83 1821 FAHLMAN@CMU-CS-C.ARPA implied contracts in the mapping functions?
C00175 00029 ∂17-Sep-83 2011 @MIT-MC:Cassels%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
C00178 00030 ∂18-Sep-83 1624 @MIT-ML:Moon%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
C00180 00031 ∂18-Sep-83 1732 @MIT-ML,@MIT-MC:kmp@MIT-MC implied contracts in the mapping functions?
C00189 00032 ∂18-Sep-83 2158 FAHLMAN@CMU-CS-C.ARPA implied contracts in the mapping functions?
C00193 00033 ∂19-Sep-83 0335 DDYER@USC-ISIB "optimizations"
C00196 00034 ∂19-Sep-83 0548 RAM@CMU-CS-C.ARPA Implicit contracts
C00198 00035 ∂19-Sep-83 0811 @MIT-MC:BSG%SCRC-TENEX@MIT-MC "optimizations"
C00201 00036 ∂19-Sep-83 1231 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Implicit contracts
C00204 00037 ∂19-Sep-83 1307 @MIT-ML:HEDRICK@RUTGERS.ARPA Re: implied contracts in the mapping functions?
C00206 00038 ∂19-Sep-83 1415 DDYER@USC-ISIB Re: "optimizations"
C00214 00039 ∂21-Sep-83 1336 @MIT-MC:DLW%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
C00215 00040 ∂21-Sep-83 1401 KMP@MIT-MC definition/errors/...
C00217 00041 ∂21-Sep-83 1508 masinter.pa@PARC-MAXC.ARPA Portability and performance, standards and change
C00220 00042 ∂22-Sep-83 1225 @MIT-ML:DLW@SCRC-TENEX Re: implied contracts in the mapping functions?
C00223 00043 ∂22-Sep-83 1423 @MIT-ML:BENSON@SPA-NIMBUS Re: implied contracts in the mapping functions?
C00227 00044 ∂22-Sep-83 1449 HEDRICK@RUTGERS.ARPA behavior of mapping
C00229 00045 ∂22-Sep-83 2049 ALAN@MIT-MC behavior of mapping
C00232 00046 ∂27-Sep-83 1620 JonL.pa@PARC-MAXC.ARPA THROW, and MAP
C00236 00047 ∂27-Sep-83 1649 @MIT-MC:Moon%SCRC-TENEX@MIT-MC THROW, and MAP
C00241 00048 ∂27-Sep-83 1722 FAHLMAN@CMU-CS-C.ARPA THROW, and MAP
C00243 00049 ∂27-Sep-83 1942 JONL.PA@PARC-MAXC.ARPA Re: THROW, and MAP
C00245 00050 ∂28-Sep-83 0828 Guy.Steele@CMU-CS-A Re: THROW, and MAP
C00249 00051 ∂28-Sep-83 0829 Guy.Steele@CMU-CS-A THROW, again
C00250 00052 ∂28-Sep-83 1352 GSB@MIT-ML THROW, and MAP
C00253 00053 ∂28-Sep-83 2017 Guy.Steele@CMU-CS-A Burke's remarks on THROW and MAP
C00255 00054 ∂01-Oct-83 1207 RPG INIT-FILE-PATHNAME
C00257 00055 ∂01-Oct-83 1207 RPG Pathnames: duh
C00260 00056 ∂01-Oct-83 1207 RPG Duh duh duh
C00262 00057 ∂01-Oct-83 1208 RPG Decompressing
C00264 00058 ∂01-Oct-83 1208 RPG Duh duh duh
C00266 00059 ∂01-Oct-83 1208 RPG Decomposing
C00269 00060 ∂01-Oct-83 1208 RPG Random idea
C00273 00061 ∂01-Oct-83 1208 RPG Random idea
C00277 00062 ∂01-Oct-83 1209 RPG INIT-FILE-PATHNAME
C00281 00063 ∂01-Oct-83 1209 RPG Random idea: bringing back lexprs
C00287 00064 ∂01-Oct-83 1209 RPG Pathnames: duh
C00294 00065 ∂01-Oct-83 1209 RPG Pathnames: duh
C00299 00066 ∂01-Oct-83 1210 RPG Random idea: bringing back lexprs
C00303 00067 ∂01-Oct-83 1210 RPG Pathnames: duh
C00310 00068 ∂01-Oct-83 1210 RPG Random idea: bringing back lexprs
C00316 00069 ∂01-Oct-83 1206 RPG Pathnames: duh
C00319 00070 ∂01-Oct-83 1500 RPG My comments on the Excelsior manual
C00359 00071 ∂01-Oct-83 1501 RPG Moon's comments on Excelsior
C00363 00072 ∂01-Oct-83 1501 RPG Comments on Excelsior manual
C00423 00073 ∂01-Oct-83 1502 RPG Comments on Excelsior manual
C00446 00074 ∂01-Oct-83 1502 RPG More comments on excelsior
C00455 00075 ∂01-Oct-83 1503 RPG More comments on excelsior
C00467 00076 ∂01-Oct-83 1504 RPG More comments on excelsior
C00473 00077 ∂01-Oct-83 1505 RPG * * ** / // ///
C00475 00078 ∂01-Oct-83 1509 RPG 370 Common Lisp
C00478 00079 ∂01-Oct-83 1509 RPG 370 Common Lisp
C00481 00080 ∂01-Oct-83 1509 RPG Speaking of Public Domain Software
C00488 00081 ∂01-Oct-83 1509 RPG Varia
C00491 00082 ∂02-Oct-83 1759 RPG &rest args
C00493 00083 ∂03-Oct-83 0942 RPG Random idea: bringing back lexprs
C00495 00084 ∂03-Oct-83 1516 RPG Random idea: bringing back lexprs
C00499 00085 ∂03-Oct-83 1517 RPG Random idea: bringing back lexprs
C00501 00086 ∂03-Oct-83 1601 RPG Random idea: bringing back lexprs
C00503 00087 ∂05-Oct-83 2020 @MIT-ML:ALAN@MIT-MC No No! Flush it!!
C00504 00088 ∂05-Oct-83 2044 HEDRICK@RUTGERS.ARPA Re: No No! Flush it!!
C00506 00089 ∂05-Oct-83 2052 FAHLMAN@CMU-CS-C.ARPA No No! Flush it!!
C00507 00090 ∂05-Oct-83 2112 GSB@MIT-ML No No! Flush it!!
C00508 00091 ∂05-Oct-83 2229 @MIT-ML:ALAN@MIT-MC No No! Flush it!!
C00511 00092 ∂05-Oct-83 2252 FAHLMAN@CMU-CS-C.ARPA No No! Flush it!!
C00513 00093 ∂05-Oct-83 2351 Guy.Steele@CMU-CS-A You thought you were kidding
C00515 00094 ∂06-Oct-83 0013 FAHLMAN@CMU-CS-C.ARPA You thought you were kidding
C00517 00095 ∂06-Oct-83 0126 Guy.Steele@CMU-CS-A Really kidding, now
C00519 00096 ∂06-Oct-83 0432 NEDVED@CMU-CS-C.ARPA please route
C00522 00097 ∂07-Oct-83 0101 Guy.Steele@CMU-CS-A SETF madness :-)
C00524 00098 ∂07-Oct-83 1531 @MIT-XX:BENSON@SPA-NIMBUS SETF madness :-)
C00527 00099 ∂08-Oct-83 0728 WVANROGGEN@DEC-MARLBORO.ARPA SETF madness
C00529 00100 ∂10-Oct-83 2320 RPG Nasty issues for Common LISP Manual
C00554 00101 ∂10-Oct-83 2320 RPG [STEELE: Nasty issues for Common LISP Manual]
C00573 00102 ∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
C00609 00103 ∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
C00622 00104 ∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
C00624 00105 ∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
C00628 00106 ∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
C00633 00107 ∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
C00635 00108 ∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
C00637 00109 ∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
C00639 00110 ∂10-Oct-83 2322 RPG Yet another proposal for #+ and #-
C00644 00111 ∂10-Oct-83 2322 RPG Binding arbitration?
C00650 00112 ∂10-Oct-83 2322 RPG Binding arbitration?
C00654 00113 ∂10-Oct-83 2322 RPG #W etc
C00656 00114 ∂10-Oct-83 2322 RPG #+foo
C00659 00115 ∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
C00664 00116 ∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
C00667 00117 ∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
C00673 00118 ∂10-Oct-83 2323 RPG #+ and #- syntax
C00675 00119 ∂12-Oct-83 0642 Meehan@YALE SETF and Prolog
C00676 00120 ∂12-Oct-83 1056 LES@CMU-CS-C.ARPA Re: SETF and Prolog
C00678 00121 ∂13-Oct-83 1051 GALWAY@UTAH-20.ARPA SETF and LAMBDAs (semi-serious?)
C00681 00122 ∂13-Oct-83 1232 @MIT-MC:MOON@SCRC-TENEX SETF and LAMBDAs (semi-serious?)
C00684 00123 ∂13-Oct-83 1851 GALWAY@UTAH-20.ARPA Whoops (SETF and LAMBDAs)
C00688 00124 ∂13-Oct-83 2133 JONL.PA@PARC-MAXC.ARPA SETF madness
C00695 00125 ∂13-Oct-83 2155 Guy.Steele@CMU-CS-A SETF and LAMBDAs
C00697 00126 ∂14-Oct-83 1141 RPG Insane
C00703 00127 ∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
C00706 00128 ∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
C00709 00129 ∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
C00711 00130 ∂14-Oct-83 1142 RPG SETF and Prolog
C00712 00131 ∂14-Oct-83 1143 RPG #+ and Bob and #W and Alice
C00715 00132 ∂14-Oct-83 1143 RPG #+ and Bob and #W and Alice
C00717 00133 ∂14-Oct-83 1143 RPG Re: SETF and Prolog
C00719 00134 ∂14-Oct-83 1144 RPG #+/#-
C00721 00135 ∂14-Oct-83 1144 RPG Ted and #U and Carol and #-
C00723 00136 ∂14-Oct-83 1145 RPG SETF and LAMBDAs (semi-serious?)
C00726 00137 ∂14-Oct-83 1145 RPG SETF and LAMBDAs (semi-serious?)
C00729 00138 ∂14-Oct-83 1146 RPG Whoops (SETF and LAMBDAs)
C00733 00139 ∂14-Oct-83 1146 RPG SETF madness
C00740 00140 ∂14-Oct-83 1147 RPG SETF and LAMBDAs
C00742 00141 ∂20-Oct-83 1710 AS%HP-HULK.HP-Labs@Rand-Relay character names
C00744 00142 ∂25-Oct-83 0820 RPG Need advice on token scanning in Common LISP
C00750 00143 ∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
C00755 00144 ∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
C00767 00145 ∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
C00769 00146 ∂25-Oct-83 0823 RPG RMS replies to 15 hairy issues
C00778 00147 ∂25-Oct-83 0826 RPG Random idea
C00781 00148 ∂28-Oct-83 1602 RPG RMS replies to 15 hairy issues
C00784 00149 ∂12-Nov-83 1117 @MIT-MC:Zvona@MIT-OZ :otherwise
C00786 00150 ∂12-Nov-83 1344 @MIT-ML:Moon%SCRC-TENEX@MIT-MC :otherwise in selectq
C00789 00151 ∂12-Nov-83 1433 @MIT-MC:KMP%MIT-OZ@MIT-MC SELECTQ commentary
C00793 00152 ∂13-Nov-83 2234 RPG Functionp
C00795 00153 ∂13-Nov-83 2234 RPG Functionp
C00797 00154 ∂24-Nov-83 1151 RPG URGENT! Problem with MACROLET.
C00803 00155 ∂24-Nov-83 1151 RPG URGENT! Problem with MACROLET.
C00805 00156 ∂24-Nov-83 1151 RPG SETF madness, again (serious)
C00809 00157 ∂24-Nov-83 1152 RPG SETF madness, again (serious)
C00810 00158 ∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
C00812 00159 ∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
C00815 00160 ∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
C00818 00161 ∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
C00825 00162 ∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
C00828 00163 ∂24-Nov-83 1152 RPG SETF madness, again (serious)
C00833 00164 ∂24-Nov-83 1152 RPG SETF madness, again (serious)
C00835 00165 ∂24-Nov-83 1153 RPG URGENT! Problem with MACROLET.
C00838 00166 ∂24-Nov-83 1153 RPG Re: SETF madness, again (serious)
C00840 00167 ∂24-Nov-83 1509 RPG Macrolet
C00843 00168 ∂26-Nov-83 1322 RPG Varia
C00844 00169 ∂26-Nov-83 1534 @MIT-ML:MOON@SCRC-TENEX Macrolet
C00850 00170 ∂29-Nov-83 0914 RPG Macrolet
C00852 00171 ∂29-Nov-83 0914 RPG &rest environments
C00854 00172 ∂29-Nov-83 0915 RPG Re: &rest environments
C00857 00173 ∂29-Nov-83 0915 RPG &rest environments
C00862 00174 ∂29-Nov-83 0915 RPG &rest environments
C00864 00175 ∂29-Nov-83 0917 RPG Macrolet
C00870 00176 ∂29-Nov-83 0917 RPG Re: SETF madness, again (serious)
C00873 00177 ∂29-Nov-83 0917 RPG &rest environments
C00876 00178 ∂29-Nov-83 0918 RPG Re: Macrolet
C00878 00179 ∂29-Nov-83 0921 RPG $rest environments
C00879 00180 ∂29-Nov-83 0921 RPG &rest environments
C00881 00181 ∂29-Nov-83 0922 RPG MACROLET, environments, etc.
C00883 00182 ∂30-Nov-83 1040 Guy.Steele@CMU-CS-A Absolutely last changes to Common LISP
C01032 00183 ∂05-Dec-83 0843 @MIT-MC:BSG@SCRC-TENEX :IF-EXISTS :SUPERSEDE vs. :NEWEST
C01037 00184 ∂05-Dec-83 0921 WHOLEY@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE vs. :NEWEST
C01039 00185 ∂05-Dec-83 0928 FAHLMAN@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE vs. :NEWEST
C01043 00186 ∂05-Dec-83 2015 @MIT-ML:Moon%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
C01050 00187 ∂06-Dec-83 0730 @MIT-MC:BSG%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
C01053 00188 ∂06-Dec-83 0729 @MIT-MC:BSG%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
C01056 00189 ∂06-Dec-83 1256 @MIT-MC:Moon%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
C01063 00190 ∂06-Dec-83 1435 FAHLMAN@CMU-CS-C.ARPA Exporting Structures
C01065 00191 ∂06-Dec-83 1832 FAHLMAN@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE
C01067 00192 ∂06-Dec-83 1939 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Exporting Structures
C01071 00193 ∂06-Dec-83 2002 FAHLMAN@CMU-CS-C.ARPA Exporting Structures
C01074 00194 ∂07-Dec-83 0928 @MIT-MC:CWH%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE vs. :NEWEST
C01082 00195 ∂08-Dec-83 2206 pierson%digital%Digital@CSNet-Relay Copy-Seq
C01084 00196 ∂08-Dec-83 2221 WHOLEY@CMU-CS-C.ARPA Copy-Seq
C01086 00197 ∂09-Dec-83 1112 Mailer@MIT-XX Copy-Seq
C01089 00198 ∂09-Dec-83 2120 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Comments on changes in Mary Poppins edition
C01095 00199 ∂13-Dec-83 2258 Guy.Steele@CMU-CS-A Reply to RMS questions about potential numbers
C01103 00200 ∂14-Dec-83 1522 GREEK@DEC-MARLBORO.ARPA Potential numbers
C01104 00201 ∂14-Dec-83 1604 FAHLMAN@CMU-CS-C.ARPA Potential numbers
C01107 00202 ∂14-Dec-83 2150 Guy.Steele@CMU-CS-A Get rid of *READ-BASE* ?
C01109 00203 ∂16-Dec-83 2014 Guy.Steele@CMU-CS-A Special declarations
C01112 00204 ∂18-Dec-83 2236 @MIT-ML:Moon%SCRC-TENEX@MIT-ML Comments on Mary Poppins Chapter 9
C01118 00205 ∂20-Dec-83 1252 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Declarations
C01130 00206 ∂20-Dec-83 1826 FAHLMAN@CMU-CS-C.ARPA Declarations
C01133 00207 ∂20-Dec-83 1849 FAHLMAN@CMU-CS-C.ARPA Comments on Mary Poppins Chapter 9
C01136 00208 ∂21-Dec-83 1847 Guy.Steele@CMU-CS-A Forwarded mail
C01138 00209 ∂21-Dec-83 1846 Guy.Steele@CMU-CS-A Interchange of interest
C01142 00210 ∂21-Dec-83 1858 Guy.Steele@CMU-CS-A Re: must be wrong
C01144 00211 ∂21-Dec-83 2021 ALAN@MIT-MC must be wrong
C01147 00212 ∂22-Dec-83 2221 @MIT-MC:Benson%SPA-NIMBUS@MIT-MC Unrelated issue re: special declarations
C01150 00213 ∂23-Dec-83 0510 GSB@MIT-MC Unrelated issue re: special declarations
C01152 00214 ∂27-Dec-83 2151 @MIT-ML:Moon%SCRC-TENEX@MIT-MC single-float-epsilon
C01155 00215 ∂27-Dec-83 2152 @MIT-ML:Moon%SCRC-TENEX@MIT-MC single-float-epsilon
C01158 00216 ∂29-Dec-83 1902 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Query about UNION
C01161 00217 ∂30-Dec-83 1445 @MIT-ML:Moon%SCRC-TENEX@MIT-MC query about make-broadcast-stream
C01163 00218 ∂30-Dec-83 1605 KMP@MIT-MC
C01165 00219 ∂30-Dec-83 1621 FAHLMAN@CMU-CS-C.ARPA Union and friends
C01167 00220 ∂30-Dec-83 2144 Guy.Steele@CMU-CS-A UNION and friends
C01168 00221 ∂02-Jan-84 0903 FAHLMAN@CMU-CS-C.ARPA query about make-broadcast-stream
C01171 00222 ∂02-Jan-84 0941 KMP@MIT-MC Sad historical sidelights: Return values -- NIL vs undefined
C01174 00223 ∂02-Jan-84 1227 @MIT-ML:Moon%SCRC-TENEX@MIT-MC query about make-broadcast-stream
C01178 00224 ∂03-Jan-84 1417 @MIT-ML:MOON@SCRC-TENEX Order of arguments to :test functions
C01181 00225 ∂03-Jan-84 1556 @MIT-ML:MOON@SCRC-TENEX Proposed new type expression
C01185 00226 ∂03-Jan-84 2010 FAHLMAN@CMU-CS-C.ARPA Proposed new type expression
C01187 00227 ∂05-Jan-84 0711 jrg@cmu-cs-spice extending or correcting common lisp
C01189 00228 ∂05-Jan-84 1805 GREEK@DEC-MARLBORO.ARPA A nit and a suggestion for the future.
C01191 00229 ∂08-Jan-84 1806 @MIT-MC:PGS%MIT-OZ@MIT-MC suggestion for the future.
C01194 00230 ∂09-Jan-84 1144 GREEK@DEC-MARLBORO.ARPA Doc Strings for DEFSTRUCT
C01196 00231 ∂09-Jan-84 1212 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Documenting defstruct slots
C01199 00232 ∂09-Jan-84 1231 KMP@MIT-MC Structures, documentation
C01207 00233 ∂10-Jan-84 2047 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Questions about COERCE
C01209 00234 ∂11-Jan-84 0813 FAHLMAN@CMU-CS-C.ARPA Questions about COERCE
C01212 00235 ∂11-Jan-84 1721 GREEK@DEC-MARLBORO.ARPA COERCE
C01213 00236 ∂17-Jan-84 1835 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Query about definition of COMMON data type
C01215 00237 ∂12-Jan-84 0809 FAHLMAN@CMU-CS-C.ARPA Flavors
C01220 00238 ∂12-Jan-84 1554 @MIT-ML:HIC%SCRC-TENEX@MIT-MC Flavors
C01225 00239 ∂12-Jan-84 1838 FAHLMAN@CMU-CS-C.ARPA Flavors
C01229 00240 ∂12-Jan-84 2011 @MIT-ML:hic%SCRC-TENEX@MIT-MC Flavors
C01234 00241 ∂12-Jan-84 2048 FAHLMAN@CMU-CS-C.ARPA Flavors
C01237 00242 ∂12-Jan-84 2219 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Flavors
C01239 00243 ∂02-Feb-84 2127 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA 1984 LISP Conference submissions deadline moved back
C01242 00244 ∂06-Feb-84 2050 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Request for clarification of DECODE-UNIVERSAL-TIME
C01244 00245 ∂22-Feb-84 1847 GSB@MIT-MC 1.0e+6 vs 1.0E+6, more food for thought
C01247 00246 ∂23-Feb-84 0939 @MIT-MC:Cassels@SCRC-TENEX 1.0e+6 vs 1.0E+6, more food for thought
C01252 00247 ∂23-Feb-84 1638 WVANROGGEN@DEC-MARLBORO.ARPA Re: 1.0e+6 vs 1.0E+6, more food for thought
C01254 00248 ∂12-Mar-84 1354 @MIT-MC:benson@SPA-NIMBUS ARRAY-DIMENSIONS
C01255 00249 ∂21-Mar-84 1850 GS70@CMU-CS-A Can you dig it
C01258 00250 ∂23-Mar-84 2248 GS70@CMU-CS-A Common Lisp Reference Manual
C01264 00251 ∂24-Apr-84 1200 SHEBS@UTAH-20.ARPA Stream Buffering Question
C01266 00252 ∂24-Apr-84 1820 @MIT-MC:Moon%SCRC-TENEX@SCRC-RIVERSIDE Stream Buffering Question
C01269 00253 ∂24-Apr-84 1852 FAHLMAN@CMU-CS-C.ARPA Stream Buffering Question
C01271 00254 ∂04-May-84 1140 wile@ISI-VAXA I'd like on mailing list
C01272 00255 ∂04-May-84 1742 @MIT-MC:Moon%SCRC-TENEX@SCRC-RIVERSIDE question about REQUIRE
C01274 00256 ∂08-May-84 1456 WVANROGGEN@DEC-MARLBORO.ARPA REQUIRE
C01276 00257 ∂01-Jun-84 0527 DLW@SCRC-STONY-BROOK.ARPA Meeting at the ACM Symposium
C01278 00258 ∂02-Jun-84 1857 masinter.pa@Xerox.ARPA ANSI Lisp
C01279 00259 ∂04-Jun-84 0747 WVANROGGEN@DEC-MARLBORO.ARPA macroexpansion environments
C01283 00260 ∂04-Jun-84 1238 Moon@SCRC-STONY-BROOK.ARPA macroexpansion environments
C01286 00261 ∂05-Jun-84 0402 DLW@SCRC-STONY-BROOK.ARPA Kyoto Common Lisp
C01288 00262 ∂05-Jun-84 0621 WVANROGGEN@DEC-MARLBORO.ARPA Re: macroexpansion environments
C01290 00263 ∂05-Jun-84 0710 FAHLMAN@CMU-CS-C.ARPA Kyoto Common Lisp
C01293 00264 ∂09-Jun-84 1123 @MIT-ML:DLW@SCRC-TENEX Manuals
C01294 00265 ∂09-Jun-84 1312 SHEBS@UTAH-20.ARPA Leakiness and Kernels
C01297 00266 ∂09-Jun-84 1437 HEDRICK@RUTGERS.ARPA Re: Leakiness and Kernels
C01300 00267 ∂09-Jun-84 1558 FAHLMAN@CMU-CS-C.ARPA Leakiness and Kernels
C01304 00268 ∂13-Jun-84 0953 DLW@SCRC-STONY-BROOK.ARPA Re: Leakiness and Kernels
C01306 00269 ∂14-Jun-84 2039 FAHLMAN@CMU-CS-C.ARPA Last-minute change
C01307 00270 ∂15-Jun-84 2208 HEDRICK@RUTGERS.ARPA request for list of changes
C01309 00271 ∂20-Jun-84 2152 GS70@CMU-CS-A.ARPA "ANSI Lisp" rumor
C01312 00272 ∂22-Jun-84 1342 HEDRICK@RUTGERS.ARPA request for information about implementations
C01314 00273 ∂24-Jun-84 2014 HEDRICK@RUTGERS.ARPA [HAUTIN@RUTGERS.ARPA: common lisp]
C01319 00274 ∂30-Jun-84 1524 SHEBS@UTAH-20.ARPA Pathname Questions
C01321 00275 ∂02-Jul-84 1526 AS%hp-hulk.csnet@csnet-relay.arpa &REST in DEFMACRO
C01323 00276 ∂06-Jul-84 1746 AS%hp-hulk.csnet@csnet-relay.arpa Query about IN-PACKAGE
C01325 00277 ∂06-Jul-84 2013 FAHLMAN@CMU-CS-C.ARPA Query about IN-PACKAGE
C01327 00278 ∂06-Jul-84 2301 GS70@CMU-CS-A.ARPA Re: &REST in DEFMACRO
C01329 00279 ∂06-Jul-84 2317 GS70@CMU-CS-A.ARPA Re: Query about IN-PACKAGE
C01330 00280 ∂10-Jul-84 1006 AS%hp-hulk.csnet@csnet-relay.arpa Re: Query about IN-PACKAGE
C01332 00281 ∂11-Jul-84 1926 Moon@SCRC-STONY-BROOK.ARPA Pathname Questions
C01335 00282 ∂13-Jul-84 1423 AS%hp-hulk.csnet@csnet-relay.arpa extended tokens?
C01337 00283 ∂13-Jul-84 1425 AS%hp-hulk.csnet@csnet-relay.arpa the meaning of #,
C01340 00284 ∂13-Jul-84 1925 Moon@SCRC-STONY-BROOK.ARPA the meaning of #,
C01344 00285 ∂15-Jul-84 0855 WVANROGGEN@DEC-MARLBORO.ARPA #,
C01346 00286 ∂15-Jul-84 0952 FAHLMAN@CMU-CS-C.ARPA #,
C01349 00287 ∂16-Jul-84 2056 GS70@CMU-CS-A.ARPA Forwarded mail
C01351 00288 ∂16-Jul-84 2057 GS70@CMU-CS-A.ARPA Re: t, nil & the package system.
C01352 00289 ∂17-Jul-84 0612 WVANROGGEN@DEC-MARLBORO.ARPA Re: #,
C01355 00290 ∂18-Jul-84 0823 RPG Drag
C01357 00291 ∂18-Jul-84 0823 RPG
C01358 00292 ∂18-Jul-84 0825 RPG Drag
C01364 00293 ∂18-Jul-84 0826 RPG Drag
C01367 00294 ∂27-Jul-84 0623 G.TI.CSL@UTEXAS-20.ARPA validation suite
C01369 00295 ∂27-Jul-84 1244 Moon@SCRC-QUABBIN.ARPA validation suite (Steve Ford)
C01372 00296 ∂02-Aug-84 0737 DLW@SCRC-STONY-BROOK.ARPA Data General
C01375 00297 ∂02-Aug-84 1514 RPG Common Lisp Meeting
C01380 00298 ∂02-Aug-84 1948 FAHLMAN@CMU-CS-C.ARPA Common Lisp Meeting
C01382 00299 ∂03-Aug-84 2356 FAHLMAN@CMU-CS-C.ARPA [decvax!mulga!bruce.csirovlsi: Apparent Commonlisp stupidity]
C01387 00300 ∂05-Aug-84 1110 RAM@CMU-CS-C.ARPA *print-case* and *print-escape*
C01389 00301 ∂13-Aug-84 0944 Moon@SCRC-STONY-BROOK.ARPA *print-case* and *print-escape*
C01392 00302 ∂13-Aug-84 0953 Moon@SCRC-STONY-BROOK.ARPA Timezones offset by non-integral hours
C01397 00303 ∂13-Aug-84 0953 Moon@SCRC-STONY-BROOK.ARPA Timezones offset by non-integral hours
C01402 00304 ∂14-Aug-84 1059 STEELE@TL-20A.ARPA Requests for clarification
C01405 00305 ∂15-Aug-84 1614 RPG Validation through Litigation
C01409 00306 ∂15-Aug-84 1821 JonL.pa@Xerox.ARPA Re: bug in assoc
C01411 00307 ∂15-Aug-84 1940 FAHLMAN@CMU-CS-C.ARPA Validation through Litigation
C01413 00308 ∂15-Aug-84 1944 RPG Just....
C01414 00309 ∂15-Aug-84 2018 FAHLMAN@CMU-CS-C.ARPA Just....
C01417 00310 ∂17-Aug-84 1143 RPG DARPA
C01419 00311 ∂17-Aug-84 1506 DLW@SCRC-STONY-BROOK.ARPA DARPA
C01421 00312 ∂18-Aug-84 1124 Moon@SCRC-QUABBIN.ARPA declarations in body of LABELS
C01423 00313 ∂18-Aug-84 1622 RAM@CMU-CS-C.ARPA Requests for clarification
C01427 00314 ∂18-Aug-84 2135 Moon@SCRC-STONY-BROOK.ARPA Requests for clarification
C01432 00315 ∂18-Aug-84 2138 Moon@SCRC-STONY-BROOK.ARPA Requests for clarification
C01435 00316 ∂19-Aug-84 1408 RPG Meeting
C01439 00317 ∂19-Aug-84 1411 RPG CLCRIT and numerics
C01441 00318 ∂19-Aug-84 1415 RPG CDC Common Lisp
C01443 00319 ∂19-Aug-84 1417 RPG Ohlander
C01445 00320 ∂19-Aug-84 1419 RPG Common Lisp meeting
C01449 00321 ∂19-Aug-84 1430 RPG possible common lisp meeting on iterative notations
C01451 00322 ∂19-Aug-84 1434 RPG The Monterey CL Conference
C01453 00323 ∂19-Aug-84 1436 RPG Re: Common Lisp meeting
C01457 00324 ∂19-Aug-84 1437 RPG Common Lisp meeting
C01459 00325 ∂19-Aug-84 1437 RPG Monterey
C01461 00326 ∂19-Aug-84 1437 RPG Re: Common Lisp meeting
C01462 00327 ∂19-Aug-84 1438 RPG Re: Monterey
C01464 00328 ∂19-Aug-84 1438 RPG Monterey
C01465 00329 ∂19-Aug-84 1438 RPG Monterey
C01467 00330 ∂19-Aug-84 1440 RPG Steele
C01469 00331 ∂19-Aug-84 1440 RPG
C01471 00332 ∂19-Aug-84 1441 RPG Common Lisp meeting
C01474 00333 ∂19-Aug-84 1445 RPG More people
C01476 00334 ∂19-Aug-84 1445 RPG DARPA
C01479 00335 ∂19-Aug-84 1447 RPG Re:
C01483 00336 ∂20-Aug-84 1139 sjk@sri-spam mailing list
C01484 00337 ∂20-Aug-84 2027 WVANROGGEN@DEC-MARLBORO.ARPA Re: Requests for clarification
C01486 00338 ∂21-Aug-84 1030 STEELE@TL-20A.ARPA Strange encounter on the Indiana Tollway
C01489 00339 ∂21-Aug-84 1901 GS70@CMU-CS-A.ARPA From Frederking
C01492 00340 ∂21-Aug-84 1935 ALAN@MIT-MC From Frederking
C01493 00341 ∂21-Aug-84 1937 GS70@CMU-CS-A.ARPA Re: CommonLisp (vs. VaxLisp) question
C01495 00342 ∂23-Aug-84 0842 ref@cmu-cs-cad.arpa Painful retraction
C01497 00343 ∂23-Aug-84 1104 FAHLMAN@CMU-CS-C.ARPA Painful retraction
C01500 00344 ∂23-Aug-84 1112 ALAN@MIT-MC Painful retraction
C01502 00345 ∂23-Aug-84 1433 WVANROGGEN@DEC-MARLBORO.ARPA structure references
C01504 00346 ∂23-Aug-84 1756 JonL.pa@Xerox.ARPA Re: Painful retraction
C01506 00347 ∂23-Aug-84 1935 GS70@CMU-CS-A.ARPA Retraction
C01509 00348 ∂24-Aug-84 0930 Moon@SCRC-QUABBIN.ARPA Painful retraction
C01512 00349 ∂24-Aug-84 1003 CWH@SCRC-QUABBIN.ARPA Type-checking structure references
C01514 00350 ∂24-Aug-84 1529 BSG@SCRC-RIVERSIDE.ARPA Painful retraction
C01517 00351 ∂25-Aug-84 0620 FAHLMAN@CMU-CS-C.ARPA Painful retraction
C01521 00352 ∂26-Aug-84 1315 RPG
C01524 00353 ∂26-Aug-84 1841 DLW@SCRC-STONY-BROOK.ARPA Questions from M. Hagiya
C01535 00354 ∂26-Aug-84 2025 WHOLEY@CMU-CS-C.ARPA Questions from M. Hagiya
C01543 00355 ∂27-Aug-84 0558 @MIT-MC:Cassels@SCRC-QUABBIN Questions from M. Hagiya
C01545 00356 ∂27-Aug-84 0627 @MIT-MC:mly@MIT-MC Questions from M. Hagiya
C01547 00357 ∂27-Aug-84 0640 DLW@SCRC-RIVERSIDE.ARPA Questions from M. Hagiya
C01552 00358 ∂27-Aug-84 0746 WHOLEY@CMU-CS-C.ARPA Rationalize
C01555 00359 ∂27-Aug-84 1245 Moon@SCRC-QUABBIN.ARPA Questions from M. Hagiya
C01558 00360 ∂27-Aug-84 1301 Moon@SCRC-QUABBIN.ARPA Rationalize
C01560 00361 ∂27-Aug-84 2045 RZ@MIT-MC Rationalize
C01564 00362 ∂28-Aug-84 0815 DLW@SCRC-QUABBIN.ARPA Rationalize
C01566 00363 ∂28-Aug-84 1215 Cassels@SCRC-STONY-BROOK.ARPA Rationalize
C01570 00364 ∂29-Aug-84 2011 Moon@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
C01574 00365 ∂30-Aug-84 0644 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
C01577 00366 ∂30-Aug-84 1344 Moon@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
C01580 00367 ∂31-Aug-84 1613 Moon@SCRC-STONY-BROOK.ARPA documentation strings
C01581 00368 ∂31-Aug-84 1727 Moon@SCRC-QUABBIN.ARPA applyhook
C01583 00369 ∂01-Sep-84 1602 EAK@MIT-MC Questions from M. Hagiya
C01586 00370 ∂01-Sep-84 1645 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-AI Re: Questions from M. Hagiya
C01590 00371 ∂01-Sep-84 1845 FAHLMAN@CMU-CS-C.ARPA Questions from M. Hagiya
C01593 00372 ∂01-Sep-84 2157 rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA "initial segments of the continued fraction lead to the best rational approximations"
C01595 00373 ∂02-Sep-84 1404 KMP@MIT-MC documentation strings
C01599 00374 ∂02-Sep-84 1845 GSB@MIT-MC (defmacro foo (&whole w) ...)
C01601 00375 ∂02-Sep-84 2055 JonL.pa@Xerox.ARPA Re: (defmacro foo (&whole w) ...)
C01602 00376 ∂02-Sep-84 2132 GSB@MIT-MC Re: (defmacro foo (&whole w) ...) macros ==> documentation strings
C01604 00377 ∂02-Sep-84 2144 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
C01607 00378 ∂02-Sep-84 2217 FAHLMAN@CMU-CS-C.ARPA applyhook
C01610 00379 ∂02-Sep-84 2245 ALAN@MIT-MC (defmacro foo (&whole w) ...)
C01613 00380 ∂03-Sep-84 0657 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
C01617 00381 ∂03-Sep-84 0737 RAM@CMU-CS-C.ARPA applyhook
C01619 00382 ∂03-Sep-84 0850 FAHLMAN@CMU-CS-C.ARPA applyhook
C01622 00383 ∂03-Sep-84 1550 ALAN@MIT-MC (defmacro foo (&whole w) ...)
C01625 00384 ∂03-Sep-84 1646 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
C01628 00385 ∂03-Sep-84 1722 ALAN@MIT-MC (defmacro foo (&whole w) ...)
C01631 00386 ∂03-Sep-84 1802 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
C01634 00387 ∂03-Sep-84 1824 GSB@MIT-MC (defmacro foo (&whole w) ...)
C01636 00388 ∂03-Sep-84 2257 GS70@CMU-CS-A.ARPA '(lambda () a)
C01638 00389 ∂03-Sep-84 2343 masinter.pa@Xerox.ARPA &whole
C01640 00390 ∂04-Sep-84 1552 JonL.pa@Xerox.ARPA Re: (defmacro foo (&whole w) ...)
C01643 00391 ∂04-Sep-84 2336 DLW@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
C01645 00392 ∂05-Sep-84 0119 Moon@SCRC-QUABBIN.ARPA applyhook
C01648 00393 ∂05-Sep-84 0119 Moon@SCRC-QUABBIN.ARPA &whole
C01650 00394 ∂05-Sep-84 0706 FAHLMAN@CMU-CS-C.ARPA &whole
C01653 00395 ∂05-Sep-84 0724 FAHLMAN@CMU-CS-C.ARPA applyhook
C01656 00396 ∂05-Sep-84 0801 Moon@SCRC-QUABBIN.ARPA documentation strings
C01659 00397 ∂05-Sep-84 0809 Moon@SCRC-QUABBIN.ARPA (defmacro foo (&whole w) ...)
C01662 00398 ∂05-Sep-84 1145 goldman@ISI-VAXA please add me to the mailing list
C01663 00399 ∂05-Sep-84 1249 Moon@SCRC-STONY-BROOK.ARPA applyhook
C01667 00400 ∂05-Sep-84 1345 Moon@SCRC-STONY-BROOK.ARPA &whole
C01672 00401 ∂05-Sep-84 1421 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
C01673 00402 ∂05-Sep-84 1542 JonL.pa@Xerox.ARPA Re: &whole
C01675 00403 ∂05-Sep-84 1837 FAHLMAN@CMU-CS-C.ARPA &whole
C01678 00404 ∂05-Sep-84 2213 Moon@SCRC-QUABBIN.ARPA Re: applyhook
C01680 00405 ∂06-Sep-84 0614 DLW@SCRC-STONY-BROOK.ARPA &whole
C01682 00406 ∂06-Sep-84 0827 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
C01684 00407 ∂06-Sep-84 1512 KMP@MIT-MC applyhook
C01688 00408 ∂06-Sep-84 1516 KMP@MIT-MC More (unrelated) EVALHOOK issues
C01691 00409 ∂06-Sep-84 2258 DDYER@USC-ISIB.ARPA Re: More (unrelated) EVALHOOK issues
C01693 00410 ∂07-Sep-84 1104 FAHLMAN@CMU-CS-C.ARPA &whole
C01695 00411 ∂07-Sep-84 1340 KMP@MIT-MC EVALHOOK maintaining independent evaluation stacks
C01701 00412 ∂07-Sep-84 1558 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
C01703 00413 ∂10-Sep-84 0024 GSB@MIT-MC applyhook and environments
C01707 00414 ∂11-Sep-84 1236 RPG common-lisp mailing list
C01709 00415 ∂12-Sep-84 0824 Moon@SCRC-STONY-BROOK.ARPA [Postmaster at SCRC-STONY-BROOK: Unable to deliver letter]
C01714 00416 ∂12-Sep-84 2309 GS70@CMU-CS-A.ARPA German -> English translator wanted
C01715 00417 ∂13-Sep-84 1035 STEELE@TL-20A.ARPA
C01719 00418 ∂13-Sep-84 1822 BSG@SCRC-STONY-BROOK.ARPA Sequence function predicate arg order
C01722 00419 ∂13-Sep-84 1825 Moon@SCRC-STONY-BROOK.ARPA Sequence function predicate arg order
C01725 00420 ∂14-Sep-84 1313 DLW@SCRC-STONY-BROOK.ARPA External symbols and inheritance
C01726 00421 ∂14-Sep-84 1315 fateman%ucbdali@Berkeley several questions, some trivial
C01729 00422 ∂14-Sep-84 1634 RAM@CMU-CS-C.ARPA External symbols and inheritance
C01732 00423 ∂15-Sep-84 1557 FAHLMAN@CMU-CS-C.ARPA External symbols and inheritance
C01734 00424 ∂15-Sep-84 1633 FAHLMAN@CMU-CS-C.ARPA several questions, some trivial
C01739 00425 ∂18-Sep-84 1044 joseph@SCRC-STONY-BROOK.ARPA Unable to deliver letter
C01743 00426 ∂20-Sep-84 1057 WHOLEY@CMU-CS-C.ARPA As long as we're sending out songs...
C01747 00427 ∂20-Sep-84 1116 WHOLEY@CMU-CS-C.ARPA Sorry...
C01748 00428 ∂22-Sep-84 0811 FAHLMAN@CMU-CS-C.ARPA Getting organized
C01751 00429 ∂22-Sep-84 1104 RPG Chairman
C01760 00430 ∂22-Sep-84 1345 FAHLMAN@CMU-CS-C.ARPA Xerox
C01767 00431 ∂22-Sep-84 1700 AS%hp-hulk.csnet@csnet-relay.arpa more questions
C01772 00432 ∂22-Sep-84 2135 REM%IMSSS.#Pup@SU-SCORE.ARPA Common-LISP book questions and errors?
C01774 00433 ∂23-Sep-84 0503 RAM@CMU-CS-C.ARPA more questions
C01782 00434 ∂23-Sep-84 0816 FAHLMAN@CMU-CS-C.ARPA Common-LISP book questions and errors?
C01785 00435 ∂23-Sep-84 1604 RPG Mailing list administrivia
C01788 00436 ∂23-Sep-84 1647 RPG Working Groups
C01790 00437 ∂23-Sep-84 1800 REM%IMSSS.#Pup@SU-SCORE.ARPA Questions about specification and possible implementations
C01797 00438 ∂24-Sep-84 0943 RPG Re: Working Groups
C01799 00439 ∂24-Sep-84 0947 FAHLMAN@CMU-CS-C.ARPA Online documents
C01803 00440 ∂24-Sep-84 0952 RPG Common Lisp groups
C01805 00441 ∂24-Sep-84 0953 RPG Mailing lists
C01806 00442 ∂24-Sep-84 0957 RPG Add to Common Lisp SIGs
C01807 00443 ∂24-Sep-84 1000 RPG Re: Working Groups
C01809 00444 ∂24-Sep-84 1007 RPG Online documents
C01811 00445 ∂24-Sep-84 1013 STEELE@TL-20A.ARPA Online documents
C01813 00446 ∂24-Sep-84 1032 RPG Re: Committees
C01816 00447 ∂24-Sep-84 1033 RPG report of meeting about Common Lisp
C01845 00448 ∂24-Sep-84 1033 FAHLMAN@CMU-CS-C.ARPA Online documents
C01848 00449 ∂24-Sep-84 1053 FAHLMAN@CMU-CS-C.ARPA Subgroups
C01851 00450 ∂24-Sep-84 1057 RPG Mailing list administrivia
C01854 00451 ∂24-Sep-84 1058 RPG Contracts with Digital Press
C01857 00452 ∂24-Sep-84 1116 RPG LISP mailing list
C01859 00453 ∂24-Sep-84 1117 RPG One more little change
C01861 00454 ∂24-Sep-84 1124 RPG Online...
C01862 00455 ∂24-Sep-84 1134 RPG
C01864 00456 ∂24-Sep-84 1136 RPG Online documents
C01868 00457 ∂24-Sep-84 1137 RPG Re: CL History
C01882 00458 ∂24-Sep-84 1321 RPG
C01883 00459 ∂25-Sep-84 1017 RPG Graphics and Window subgroups
C01885 00460 ∂25-Sep-84 1019 RPG Please add me to Common Lisp.
C01886 00461 ∂25-Sep-84 1242 FAHLMAN@CMU-CS-C.ARPA Kyoto Common Lisp
C01889 00462 ∂25-Sep-84 2120 RPG Change in Teknowledge representation
C01890 00463 ∂25-Sep-84 2122 RPG
C01891 00464 ∂26-Sep-84 0756 RPG Re: Working Groups
C01892 00465 ∂27-Sep-84 1052 RPG Please add me ty your group
C01893 00466 ∂29-Sep-84 1426 @SU-SCORE.ARPA:FAHLMAN@CMU-CS-C.ARPA Questions about specification and possible implementations
C01903 00467 ∂30-Sep-84 1327 RPG Archives
C01906 00468 ∂01-Oct-84 0951 RPG Common Lisp List
C01908 00469 ∂03-Oct-84 0736 heller%umass-cs.csnet@csnet-relay.arpa Questions about OPEN
C01910 00470 ∂03-Oct-84 1131 RPG Re: Introduction
C01912 00471 ∂03-Oct-84 1518 MEEHAN@YALE.ARPA How constant are defconstants?
C01916 00472 ∂03-Oct-84 1654 RAM@CMU-CS-C.ARPA How constant are defconstants?
C01918 00473 ∂03-Oct-84 1721 FAHLMAN@CMU-CS-C.ARPA How constant are defconstants?
C01921 00474 ∂03-Oct-84 2114 SQUIRES@USC-ISI.ARPA Re: World peace
C01927 00475 ∂04-Oct-84 0414 @MIT-MC:rwg%SPA-NIMBUS@SCRC-STONY-BROOK malnumeracy
C01929 00476 ∂04-Oct-84 0544 @SU-SCORE.ARPA:Moon@SCRC-QUABBIN.ARPA Questions about specification and possible implementations
C01940 00477 ∂04-Oct-84 0544 @SU-SCORE.ARPA:Moon@SCRC-QUABBIN.ARPA Questions about specification and possible implementations
C01951 00478 ∂04-Oct-84 0817 FAHLMAN@CMU-CS-C.ARPA World peace
C01955 00479 ∂04-Oct-84 1008 fateman%ucbdali@Berkeley numbers, oh well.
C01957 00480 ∂04-Oct-84 1231 Moon@SCRC-STONY-BROOK.ARPA applyhook
C01966 00481 ∂04-Oct-84 1248 JonL.pa@Xerox.ARPA Re: How constant are defconstants?
C01969 00482 ∂04-Oct-84 1339 @SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA Re: Questions about specification and possible implementations
C01972 00483 ∂04-Oct-84 1340 KMP@MIT-MC *applyhook*
C01975 00484 ∂04-Oct-84 1423 masinter.pa@Xerox.ARPA Re: How constant are defconstants?
C01977 00485 ∂04-Oct-84 1458 @SU-SCORE.ARPA:WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
C01980 00486 ∂04-Oct-84 1545 JonL.pa@Xerox.ARPA Re: How constant are defconstants?
C01982 00487 ∂04-Oct-84 1731 Moon@SCRC-QUABBIN.ARPA numbers, oh well.
C01986 00488 ∂04-Oct-84 1739 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
C01991 00489 ∂04-Oct-84 1746 @SU-SCORE.ARPA:WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
C01999 00490 ∂04-Oct-84 1828 Moon@SCRC-QUABBIN.ARPA Questions about OPEN
C02004 00491 ∂04-Oct-84 1911 SQUIRES@USC-ISI.ARPA Re: World peace
C02006 00492 ∂04-Oct-84 1914 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
C02010 00493 ∂04-Oct-84 1934 RAM@CMU-CS-C.ARPA Questions about OPEN
C02013 00494 ∂04-Oct-84 2017 FAHLMAN@CMU-CS-C.ARPA World peace
C02016 00495 ∂04-Oct-84 2033 FAHLMAN@CMU-CS-C.ARPA Questions about OPEN
C02018 00496 ∂04-Oct-84 2212 Moon@SCRC-STONY-BROOK.ARPA Questions about OPEN
C02025 00497 ∂04-Oct-84 2347 RAM@CMU-CS-C.ARPA Questions about OPEN
C02031 00498 ∂05-Oct-84 1018 HEDRICK@RUTGERS.ARPA Re: Questions about OPEN
C02033 00499 ∂05-Oct-84 1250 RAM@CMU-CS-C.ARPA Questions about OPEN
C02035 00500 ∂05-Oct-84 1341 @SU-SCORE.ARPA:HANDERSON@CMU-CS-C.ARPA Aside about encapsulations
C02038 00501 ∂05-Oct-84 1344 HEDRICK@RUTGERS.ARPA Re: Questions about OPEN
C02044 00502 ∂05-Oct-84 1555 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
C02050 00503 ∂05-Oct-84 1815 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Aside about encapsulations
C02053 00504 ∂05-Oct-84 2046 Moon@SCRC-QUABBIN.ARPA Re: Questions about OPEN
C02057 00505 ∂05-Oct-84 2136 Moon@SCRC-QUABBIN.ARPA Questions about OPEN
C02067 00506 ∂05-Oct-84 2256 RAM@CMU-CS-C.ARPA Questions about OPEN
C02070 00507 ∂06-Oct-84 1350 RPG Mail to me
C02073 00508 ∂06-Oct-84 1351 RPG Mail to me
C02076 00509 ∂06-Oct-84 1401 RPG Working Groups
C02080 00510 ∂06-Oct-84 1523 RPG Communication difficulties
C02082 00511 ∂06-Oct-84 1931 SQUIRES@USC-ISI.ARPA Re: World peace
C02087 00512 ∂08-Oct-84 0908 RPG Re: Varia
C02090 00513 ∂08-Oct-84 1033 cpd@UCLA-LOCUS.ARPA How so I get on this List?
C02091 00514 ∂08-Oct-84 1045 cpd@UCLA-LOCUS.ARPA Benchmark - PERQ CL vs Apollo T
C02097 00515 ∂08-Oct-84 1255 WHOLEY@CMU-CS-C.ARPA Benchmark - PERQ CL vs Apollo T
C02101 00516 ∂08-Oct-84 1942 KMP@MIT-MC Questions about OPEN
C02107 00517 ∂08-Oct-84 2104 KMP@MIT-MC Maclisp interpreter/compiler nearly identical w/ (declare (special t)) on??
C02116 00518 ∂09-Oct-84 1230 PERDUE%hp-hulk.csnet@csnet-relay.arpa Re: Questions about specification and possible implementations
C02118 00519 ∂09-Oct-84 1422 WHOLEY%cmu-cs-c.arpa@csnet-relay.arpa Questions about specification and possible implementations
C02123 00520 ∂10-Oct-84 0907 jrg@cmu-cs-spice.arpa UCLA Perq
C02126 00521 ∂11-Oct-84 1824 JonL.pa%xerox.arpa@csnet-relay.arpa Re: Questions about specification and possible implementations
C02129 00522 ∂11-Oct-84 1951 WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
C02135 00523 ∂11-Oct-84 2008 FAHLMAN@CMU-CS-C.ARPA Questions about specification and possible implementations
C02138 00524 ∂11-Oct-84 2010 JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
C02140 00525 ∂11-Oct-84 2027 JonL.pa@Xerox.ARPA Re: A few more items on "Questions about specification and
C02144 00526 ∂11-Oct-84 2122 REM%IMSSS.#Pup@SU-SCORE.ARPA Fast or slow linkage re TRACE, what to put in specs?
C02154 00527 ∂11-Oct-84 2142 REM%IMSSS.#Pup@SU-SCORE.ARPA Whether interpreted&compiled code should agree initially?
C02158 00528 ∂12-Oct-84 0928 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
C02160 00529 ∂12-Oct-84 1106 FAHLMAN@CMU-CS-C.ARPA World peace
C02165 00530 ∂14-Oct-84 0800 WHOLEY@CMU-CS-C.ARPA Inconsistency in Aluminum edition
C02167 00531 ∂14-Oct-84 0822 FAHLMAN@CMU-CS-C.ARPA Inconsistency in Aluminum edition
C02169 00532 ∂15-Oct-84 0706 OHLANDER%usc-isi.arpa@csnet-relay.arpa Re: World peace
C02171 00533 ∂17-Oct-84 1206 Moon@SCRC-QUABBIN.ARPA Re: Questions about OPEN
C02175 00534 ∂17-Oct-84 2251 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
C02180 00535 ∂18-Oct-84 0105 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
C02185 00536 ∂21-Oct-84 2152 GS70@CMU-CS-A.ARPA SIGNUM in integer form
C02186 00537 ∂21-Oct-84 2152 GS70@CMU-CS-A.ARPA SIGNUM and brain damage
C02188 00538 ∂22-Oct-84 1440 AS%hp-hulk.csnet@csnet-relay.arpa Should (EVAL-WHEN (EVAL LOAD) mumble) = mumble?
C02192 00539 ∂25-Oct-84 1012 RPG Change of address
C02194 00540 ∂26-Oct-84 1046 GREEK@DEC-MARLBORO.ARPA Daylight Saving Time
C02196 00541 ∂26-Oct-84 1729 AS%hp-hulk.csnet@csnet-relay.arpa EVAL-WHEN: question about intent
C02204 00542 ∂26-Oct-84 1836 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA SIGNUM in integer form
C02206 00543 ∂03-Nov-84 0750 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA SIGNUM and brain damage
C02210 00544 ∂04-Nov-84 0428 GSB@MIT-MC cruftier contagion corollaries cause consternation
C02213 00545 ∂10-Nov-84 1657 @MIT-MC:KMP@MIT-OZ Using EQ instead of EQL to compare catch tags
C02215 00546 ∂10-Nov-84 1730 FAHLMAN@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
C02217 00547 ∂10-Nov-84 1738 WHOLEY@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
C02221 00548 ∂12-Nov-84 1012 Masinter.pa@Xerox.ARPA Re: Using EQ instead of EQL to compare catch tags
C02223 00549 ∂12-Nov-84 1051 WHOLEY@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
C02226 00550 ∂12-Nov-84 1224 KMP@MIT-MC catch/throw performance loss
C02228 00551 ∂12-Nov-84 1251 FAHLMAN@CMU-CS-C.ARPA catch/throw performance loss
C02230 00552 ∂12-Nov-84 1328 JAR@MIT-MC Using EQ instead of EQL to compare catch tags
C02233 00553 ∂12-Nov-84 1341 JonL.pa@Xerox.ARPA EQ vs EQUAL: catch/throw performance loss
C02239 00554 ∂12-Nov-84 2040 GSB@MIT-MC catch/throw performance loss
C02241 00555 ∂12-Nov-84 2122 WHOLEY@CMU-CS-C.ARPA Stability?
C02244 00556 ∂12-Nov-84 2347 masinter.pa@Xerox.ARPA Re: Stability?
C02246 00557 ∂13-Nov-84 0036 WHOLEY@CMU-CS-C.ARPA Stability?
C02250 00558 ∂15-Nov-84 1121 RPG
C02251 00559 ∂15-Nov-84 1126 RPG Common Lisp mailing lists
C02257 00560 ∂15-Nov-84 1133 RPG Varia
C02261 00561 ∂16-Nov-84 2216 ME message remailed after list corrected
C02263 00562 ∂20-Nov-84 1857 REM%IMSSS.#Pup@SU-SCORE.ARPA How to organize portable programs with sys-dep parts?
C02268 00563 ∂20-Nov-84 1859 REM%IMSSS.#Pup@SU-SCORE.ARPA How to implement partly-system-dependent mostly-portable code?
C02274 00564 ∂21-Nov-84 1111 GJC@MIT-MC left to right order of evaluation
C02276 00565 ∂21-Nov-84 1119 KMP@MIT-MC Stability?
C02282 00566 ∂21-Nov-84 1228 JAR@MIT-MC left to right order of evaluation
C02287 00567 ∂21-Nov-84 1244 FAHLMAN@CMU-CS-C.ARPA left to right order of evaluation
C02291 00568 ∂21-Nov-84 1256 @MIT-MC:BROOKS@MIT-OZ Re: left to right order of evaluation
C02294 00569 ∂21-Nov-84 1309 FAHLMAN@CMU-CS-C.ARPA left to right order of evaluation
C02296 00570 ∂21-Nov-84 1324 @MIT-MC:BROOKS@MIT-OZ Re: left to right order of evaluation
C02299 00571 ∂21-Nov-84 1526 masinter.pa@Xerox.ARPA Re: left to right order of evaluation
C02301 00572 ∂21-Nov-84 2306 GJC@MIT-MC global function namespace given too much weight perhaps?
C02303 00573 ∂22-Nov-84 1013 FAHLMAN@CMU-CS-C.ARPA global function namespace given too much weight perhaps?
C02305 00574 ∂22-Nov-84 1449 GJC@MIT-MC global function namespace given too much weight perhaps?
C02307 00575 ∂22-Nov-84 1546 JonL.pa@Xerox.ARPA Re: left to right order of evaluation
C02313 00576 ∂22-Nov-84 2059 FAHLMAN@CMU-CS-C.ARPA global function namespace given too much weight perhaps?
C02315 00577 ∂23-Nov-84 0339 REM%IMSSS.#Pup@SU-SCORE.ARPA (EQ ...) untrue for numbers?
C02317 00578 ∂23-Nov-84 1407 JAR@MIT-MC left to right order of evaluation
C02322 00579 ∂23-Nov-84 1444 REM%IMSSS.#Pup@SU-SCORE.ARPA Left to right, or parallel, evaluation of arguments to function?
C02336 00580 ∂23-Nov-84 1449 REM%IMSSS.#Pup@SU-SCORE.ARPA Being able to get list of pending CATCH tags?
C02340 00581 ∂23-Nov-84 1519 RPG List of pending catch tags
C02341 00582 ∂23-Nov-84 1548 KMP@MIT-MC memo-catch
C02343 00583 ∂23-Nov-84 1752 REM@IMSSS access to list of pending CATCH tags?
C02348 00584 ∂23-Nov-84 2008 FAHLMAN@CMU-CS-C.ARPA Being able to get list of pending CATCH tags?
C02350 00585 ∂23-Nov-84 2033 FAHLMAN@CMU-CS-C.ARPA Left to right, or parallel, evaluation of arguments to function?
C02353 00586 ∂25-Nov-84 1216 RPG Re: Left to right, or parallel, evaluation of arguments to function?
C02356 00587 ∂25-Nov-84 1217 RPG Left to right, or parallel, evaluation of arguments to function?
C02359 00588 ∂26-Nov-84 0848 RPG Re: Left to right, or parallel, evaluation of arguments to function?
C02362 00589 ∂26-Nov-84 0854 RPG Please add...
C02365 00590 ∂26-Nov-84 0955 J.Dalton%edxa@Ucl-Cs.ARPA Manual does say left to right
C02369 00591 ∂26-Nov-84 1508 RPG Ballot
C02372 00592 ∂10-Dec-84 1135 RPG loop & defmacro
C02375 00593 ∂10-Dec-84 1140 RPG Re: CL the copyright
C02378 00594 ∂10-Dec-84 2158 RPG macros qua functions allowed??
C02382 00595 ∂11-Dec-84 1323 jrg@cmu-cs-spice.arpa Re: left to right order of evaluation
C02385 00596 ∂12-Dec-84 1054 STEELE@TL-20A.ARPA Legalities
C02388 00597 ∂12-Dec-84 1112 RPG Why Lawyers Make Better Lab Animals than Rats (*)
C02390 00598 ∂12-Dec-84 1821 FAHLMAN@CMU-CS-C.ARPA Why Lawyers Make Better Lab Animals than Rats (*)
C02395 00599 ∂12-Dec-84 1822 FAHLMAN@CMU-CS-C.ARPA Why Lawyers Make Better Lab Animals than Rats (*)
C02397 00600 ∂12-Dec-84 2307 GS70@CMU-CS-A.ARPA Re: left to right order of evaluation
C02400 00601 ∂12-Dec-84 2346 GS70@CMU-CS-A.ARPA I'm the cretin
C02402 00602 ∂12-Dec-84 2347 GS70@CMU-CS-A.ARPA Re: Manual does say left to right
C02405 00603 ∂13-Dec-84 0657 STEELE@TL-20A.ARPA Rats, etc.
C02407 00604 ∂15-Dec-84 2314 masinter.pa@Xerox.ARPA recruiting
C02408 00605 ∂19-Dec-84 1856 RPG Common Lisp Specification
C02411 00606 ∂19-Dec-84 2250 GS70@CMU-CS-A.ARPA Do I really know anything about Common LISP?
C02413 00607 ∂20-Dec-84 0717 greek@DEC-HUDSON Does anyone understand :REHASH-THRESHOLD?
C02415 00608 ∂20-Dec-84 1439 RPG Common Lisp Specification
C02418 00609 ∂20-Dec-84 1439 RPG Re: Common Lisp Specification
C02420 00610 ∂21-Dec-84 0619 NET-ORIGIN@MIT-MC Does anyone understand :REHASH-THRESHOLD?
C02422 00611 ∂21-Dec-84 2235 BSG@SCRC-QUABBIN.ARPA No, I'm not joking
C02423 00612 ∂22-Dec-84 1137 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@STANFORD Re: No, I'm not joking
C02427 00613 ∂22-Dec-84 1152 RAM@CMU-CS-C.ARPA No, I'm not joking
C02429 00614 ∂22-Dec-84 1214 RAM@CMU-CS-C.ARPA No, I'm not joking
C02432 00615 ∂26-Dec-84 1201 RPG Common Lisp Specification
C02435 00616 ∂26-Dec-84 1201 RPG Re: Common Lisp Specification
C02437 00617 ∂26-Dec-84 1209 RPG AAAI
C02439 00618 ∂26-Dec-84 1332 FAHLMAN@CMU-CS-C.ARPA AAAI
C02443 00619 ∂26-Dec-84 1456 RPG Independence
C02445 00620 ∂28-Dec-84 1112 STEELE@TL-20A.ARPA Re: Independence
C02449 00621 ∂29-Dec-84 0559 NET-ORIGIN@MIT-MC Irrational GCD
C02451 00622 ∂01-Jan-85 1916 FAHLMAN@CMU-CS-C.ARPA Yellow pages
C02454 00623 ∂01-Jan-85 2003 fateman%ucbdali@Berkeley Re: Yellow pages
C02456 00624 ∂02-Jan-85 0618 OHLANDER@USC-ISI.ARPA Re: AAAI
C02457 00625 ∂02-Jan-85 0631 OHLANDER@USC-ISI.ARPA Re: Independence
C02460 00626 ∂02-Jan-85 0738 FAHLMAN@CMU-CS-C.ARPA Yellow pages
C02462 00627 ∂02-Jan-85 1332 kessler%utah-orion@utah-cs re: Yellow pages
C02468 00628 ∂02-Jan-85 1357 kessler%utah-orion@utah-cs re: Yellow pages
C02474 00629 ∂05-Jan-85 1007 @MIT-MC:ALAN@SCRC-TENEX Irrational GCD
C02479 00630 ∂07-Jan-85 0807 DLW@SCRC-STONY-BROOK.ARPA Independence
C02481 00631 ∂14-Jan-85 1523 RPG on the cl graphics list?
C02483 00632 ∂16-Jan-85 0423 JonL.pa@Xerox.ARPA Silicon Valley Syndrome
C02485 00633 ∂18-Jan-85 1453 HANDERSON@CMU-CS-C.ARPA Filtering calls
C02488 00634 ∂21-Jan-85 2002 FAHLMAN@CMU-CS-C.ARPA A proposal
C02513 00635 ∂21-Jan-85 2117 fateman%ucbdali@UCB-VAX Re: A proposal
C02517 00636 ∂22-Jan-85 0819 greek@DEC-HUDSON Problems with MAKE-HASH-TABLE
C02519 00637 ∂22-Jan-85 1015 STEELE@TL-20A.ARPA Re: A proposal
C02522 00638 ∂22-Jan-85 1112 NET-ORIGIN@MIT-MC Problems with MAKE-HASH-TABLE
C02524 00639 ∂22-Jan-85 1203 greek@DEC-HUDSON Problems with MAKE-HASH-TABLE
C02525 00640 ∂23-Jan-85 0502 WHOLEY@CMU-CS-C.ARPA Make-Hash-Table
C02530 00641 ∂23-Jan-85 0502 WHOLEY@CMU-CS-C.ARPA Make-Hash-Table
C02535 00642 ∂23-Jan-85 0743 greek@DEC-HUDSON MAKE-HASH-TABLE
C02536 ENDMK
C⊗;
∂28-Jul-83 1912 FAHLMAN@CMU-CS-C.ARPA ERROR SIGNALLING FUNCTIONS
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 Jul 83 19:12:13 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 28 Jul 83 22:12:52-EDT
Date: Thu, 28 Jul 1983 22:12 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: GBROWN@DEC-MARLBORO.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: ERROR SIGNALLING FUNCTIONS
In-reply-to: Msg of Thu 28 Jul 83 11:32:42-EDT from GBROWN at DEC-MARLBORO.ARPA
A part of Paul's note that I agree with is that, in retrospect, I don't
think that we want to have error-signalling forms that take unevaluated
string args. In most cases we will want to stick some constant string
in there, but there may well be cases where we want to evaluate any such
arg. A function that goes off somewhere to find a string in the proper
natural language is just one such application. Since the string arg in
ASSERT is used as a syntactic marker, we would have to change that
function's syntax to fix this -- the pre-string arguments would have to
be encased in a list or something like that.
We probably should think about fixing this in the second edition -- it
is not of such earth-shaking importance that we should consider
unfreezing edition 1 to put this change in. As others have pointed out,
ASSERT is just a convenient abbreviation, not a primitive.
-- Scott
∂28-Jul-83 2130 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Non-evaluated error message in ASSERT
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Jul 83 21:30:38 PDT
Received: from SCRC-BULLDOG by SCRC-TENEX with CHAOS; Fri 29-Jul-83 00:29:15-EDT
Date: Friday, 29 July 1983, 00:30-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-evaluated error message in ASSERT
To: COMMON-LISP@SU-AI
In-reply-to: The message of 28 Jul 83 22:12-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
When I first proposed the current syntax of ASSERT, I asked if
anyone wanted to change the syntax to allow the error message to
be evaluated, and no one said yes. I would be perfectly happy
to make that change and regard it as an erratum in the manual.
The current syntax is
(ASSERT test-form [reference*] [format-string] [format-arg*])
The new syntax would be
(ASSERT test-form ([reference*]) [format-string] [format-arg*])
∂28-Jul-83 2155 WHOLEY@CMU-CS-C.ARPA Non-evaluated error message in ASSERT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 28 Jul 83 21:54:58 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 29 Jul 83 00:55:44-EDT
Date: Fri, 29 Jul 1983 00:55 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Non-evaluated error message in ASSERT
In-reply-to: Msg of 29 Jul 1983 00:30-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Of course, with the current definition of ASSERT, one can still compute
format-strings by using "~?", format indirection...
∂29-Jul-83 0607 GBROWN@DEC-MARLBORO.ARPA ERROR SIGNALLING FUNCTIONS
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 29 Jul 83 06:07:34 PDT
Date: Fri 29 Jul 83 09:06:44-EDT
From: GBROWN@DEC-MARLBORO.ARPA
Subject: ERROR SIGNALLING FUNCTIONS
To: COMMON-LISP@SU-AI.ARPA
Well, I certainly want to thank everyone for taking the time to read
my message and give it some thought. I can tell that it's going to
be refreshing to work on Common Lisp in an environment where a variety of
people openly discuss the issues (I am just about to join the AI
group at Digital).
It is clear now that I was coming from a different direction. I tend
to implement a simple internal error reporting facility for an
application, and then spend most of my time on the user interface.
Thus my reaction to the functions was slanted in the direction of the
user. The functions are quite good for internal error reporting, and
it's great that developers won't have to reinvent them every time.
I do suggest that we take Dave Moon up on his willingness to change the
definition of check-type and assert so that they can evaluate their
message strings. We've had some success at Digital with message file
translation, so we might want to do that with Lisp applications. One
can still put the messages in the source; a fancy macro can do the
dirty work.
I also suggest that we think a little about how declarations interact
with the key forms of these functions.
Any day now we'll get our Lisp Machine. Thanks again.
- Paul C. Anagnostopoulos
-------
∂29-Jul-83 0807 FAHLMAN@CMU-CS-C.ARPA Non-evaluated error message in ASSERT
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Jul 83 08:07:23 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 29 Jul 83 11:07:58-EDT
Date: Fri, 29 Jul 1983 11:07 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Non-evaluated error message in ASSERT
In-reply-to: Msg of 29 Jul 1983 00:30-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
If there are no objections to the proposed change to the syntax of
ASSERT, I propose that we let Guy decide whether this "erratum" can go
into the manual at this point without undue disruption of the
proofreading/editing/production process. While changing anything that
is widely used would be unacceptable to us at this time, ASSERT is not
currently being used much in our code, and the proposed change is
trivial. CHECK-TYPE would also be changed to eval its string, but this
change is upward-compatible, or nearly so. Guy should give us a clear
go/no-go decision on this change as soon as possible.
I do remember Moon's query on this, and also that I didn't think very
long about its implications, given the amount of stuff that was being
dealt with just then.
-- Scott
∂29-Jul-83 1338 @MIT-MC:MOON%SCRC-TENEX%MIT-MC@SU-DSN Non-evaluated error message in ASSERT
Received: from MIT-MC by SU-AI with TCP/SMTP; 29 Jul 83 13:37:48 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Fri 29-Jul-83 16:34:38-EDT
Date: Friday, 29 July 1983, 16:35-EDT
From: David A. Moon <MOON%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Non-evaluated error message in ASSERT
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: COMMON-LISP@SU-AI
In-reply-to: The message of 29 Jul 83 11:07-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
CHECK-TYPE already does evaluate its optional third argument (error message).
If the manual doesn't say this, it's a mistake in the manual.
∂29-Jul-83 2131 Guy.Steele@CMU-CS-A ASSERT and CHECK-TYPE
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 29 Jul 83 21:31:18 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 30 Jul 83 00:23:39 EDT
Date: 30 Jul 83 0027 EDT (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: ASSERT and CHECK-TYPE
Per Moon's remark, that the manual states that CHECK-TYPE does not evaluate
the error-message argument is an error. CHECK-TYPE should evaluate its
optional argument form.
ASSERT should have the syntax
ASSERT test-form [ ( {place}* ) [ string {arg}* ] ]
--Guy
∂05-Aug-83 1309 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX File open options
Received: from USC-ECL by SU-AI with TCP/SMTP; 5 Aug 83 13:09:01 PDT
Received: from MIT-XX by USC-ECL; Fri 5 Aug 83 13:09:30-PDT
Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Fri 5-Aug-83 15:50:05-EDT
Date: Friday, 5 August 1983, 15:50-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: File open options
To: Common-Lisp%su-ai at USC-ECL
The Laser Manual speaks of the :IF-EXISTS options :RENAME,
:RENAME-AND-DELETE as though they do their renaming and deleting at open
time. It goes out of its way to say that :SUPERSEDE "destroys" the
existing file at successful close time. The former being unreasonable,
I decided that the Lisp Machine local file system would continue to
implement all of these concepts at successful close time. It keeps the
real file open under a funny name until then. The only place it could
possibly screw up is a direct access, interlocked, multi-process, shared
file of a kind that we currently don't have.
I guess I'm just thinking out loud, or asking for an adjudication
on the legality of such a decision.
While we are on the subject, should anything be said about open
':direction ':output ':if-exists ':overwrite closing in abort mode?
Should the file go away?
∂09-Aug-83 0809 @USC-ECL,@MIT-XX:BSG@SCRC-TENEX File opening, :TRUNCATE
Received: from USC-ECL by SU-AI with TCP/SMTP; 9 Aug 83 08:09:27 PDT
Received: from MIT-XX by USC-ECL; Tue 9 Aug 83 08:07:50-PDT
Received: from SCRC-BEAGLE by SCRC-SPANIEL with CHAOS; Tue 9-Aug-83 11:04:41-EDT
Date: Tuesday, 9 August 1983, 11:04-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: File opening, :TRUNCATE
To: Common-Lisp%SU-AI at USC-ECL
Cc: File-protocol at SCRC-TENEX
Was it ever proposed or rejected that there be a :IF-EXISTS
:TRUNCATE, being like :OVERWRITE, except that the file content
is effectively set to empty before writing starts? There is
need for such a thing, and it is a natural behavior on many
systems.
The default :IF-EXISTS of :ERROR is not useful on file systems
that do not have versions (note that a version of :NEWEST
changes the default to :NEW-VERSION). We propose that the
default :IF-EXISTS be changed to :SUPERSEDE for file sytems
that do not have versions.
Is there any reason why :IF-EXISTS is ignored in :OUTPUT/:IO
instead of generating an error?
∂14-Aug-83 1216 FAHLMAN@CMU-CS-C.ARPA Things to do
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 14 Aug 83 12:16:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 14 Aug 83 15:16:47-EDT
Date: Sun, 14 Aug 1983 15:16 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: common-lisp @ SU-AI.ARPA
Subject: Things to do
A bunch of things were put off without decisions or were patched over in
the effort to get agreement on the first edition. Most of the people
who have been intensively involved in the language design will be tied
up for another couple of months getting their implementations up to spec
and tweaking them for performance. However, it is perhaps not too soon
to begin thinking about what major additions/changes we want to get into
the second edition, so that those who want to make proposals can begin
preparing them and so that people can make their plans in light of what
is likely to be coming.
Here's a list of the major things that I see on the agenda for the next
year or so. Some are yellow-pages packages, some have deep roots
and require white-pages support, and some are so pervasive that they
will probably migrate into the white pages after a probationary period
in yellow-land. I'm sure I'm forgetting a few things that have already
been suggested. I'm also sure that people will have some additional
proposals to make. I am not including very minor and trivial changes
that we might want to make in the language as we gain some experience
with it.
1. Someone needs to implement the transcendental functions for complex
numbers in a portable way so that we can all use these. The functions
should be parameterized so that they will work for all the various
floating-point precisions that implementations might offer. The design
should be uncontroversial, since it is already specified in the manual.
I don't think we have any volunteers to do this at present.
2. We need to re-think the issue of function specs, and agree on what
should go into the white pages next time around. Moon's earlier
proposal, or some subset of it, is probably what we want to go with.
3. At one point HIC offered to propose a minimal set of white-pages
support for efficient implementation of a portable flavor system, and to
supply the portable part. The white-pages support would also be usable
by other object-oriented paradigms with different inheritance schemes
(that's the controversial part). After a brief exchange of messages,
HIC got super-busy on other matters and we haven't heard much since
then. Either HIC or someone else needs to finish this proposal, so that
we can put in the low-level support and begin playing with the portable
implementation of flavors. Only after more Common Lisp users have had
some opportunity to play with flavors will it make sense to consider
including them (or some variation) in the white pages. There is a lot
of interest in this out in user-land.
4. We need some sort of iteration facility more powerful than DO. The
existing proposals are some extensively cleaned-up revision of LOOP and
Dick Waters' LETS package. There may be some other ideas out there as
well. Probably the best way to proceed here is for the proponents of
each style to implement their package portably for the yellow pages and
let the customers decide what they like. If a clear favorite emerges,
it will probably be absorbed into the white pages, though this would not
preclude personal use of the other style. None of these things requires
white-pages support -- it is just a matter of what we want to encourage
users to use, and how strongly.
5. A good, portable, user-modifiable pretty printer is needed, and if it
were done well enough I see no reason not to put the user-visible
interface in the white pages next time around. Waters' GPRINT is one
candidate, and is being adopted as an interim pretty-printer by DEC.
The last time I looked, the code for that package was impenetrable and
the interface to it was excessively hairy, but I've heard that it has
been simplified. Maybe this is what we want to go with. Other options?
6. We need to work out the business of taxonomic error-handling. Moon
has a proposal in mind, I believe. A possible problem is that this
wants to be white-pages, so if it depends on flavors it gets tied up
with the issue of making flavors white-pages as well.
7. The Hemlock editor, a public-domain Emacs-clone written in portable
Common Lisp, is now running on the Perq and Vax implementations. We
have a lot of additional commands and modes to implement and some tuning
to do, but that should happen fairly rapidly over the next few months.
Of course, this cannot just be moved verbatim to a new implementation
and run there, since it interacts closely with screen-management and
with the file system. Once Hemlock is polished, it will provide a
reasonable minimum editing/top-level environment for any Common Lisp
implementation that takes the trouble to adapt it to the local system.
This should eliminate the need for hairy rubout-handlers, interlispy
top-levels, S-expression editors, and some other "environment" packages.
We plan to add some version of "info mode" at some point and to get the
Common Lisp Manual and yellow pages documents set up for tree-structured
access by this package, but that won't happen right away.
8. Someone ought to put together a reasonable package of macro-writer's
aids: functions that know which things can be evaluated multiple times
without producing side-effects, type-analysis hacks, and other such
goodies.
If you have items to add to this list, let me know.
-- Scott
∂15-Aug-83 1251 @MIT-MC:BENSON@SPA-NIMBUS Looping constructs
Received: from MIT-MC by SU-AI with TCP/SMTP; 15 Aug 83 12:50:58 PDT
Date: Monday, 15 August 1983, 12:29-PDT
From: Eric Benson <BENSON at SPA-Nimbus>
Subject: Looping constructs
To: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>,
common-lisp at SU-AI.ARPA
In-reply-to: The message of 14 Aug 83 12:16-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Okay, I'll jump right in...
I believe that LOOP and LetS can coexist peacefully in the same world.
They deal with two different problems in very different ways. LetS
allows APL-style processing of "sequences," (unrelated to the Common
Lisp sequence concept) with an expression based syntax. It is designed
so that sequences are not actually created as data structures, rather
existing conceptually as intermediate values. Such operations as
merging, sorting and concatentation do not fit within its paradigm.
LOOP, on the other hand, is intended to extend (all) the iteration
constructs found in other languages to Lisp, with a keyword based
syntax. This kitchen-sink-ism and non-Lispy syntax seems to offend some
purists, but there are many iterative programs which could not be
expressed at all using LetS, and only painfully using DO, which are
quite amenable to treatment with LOOP. Chacun a son gout.
(LOOP FOR EVERYONE IN COMMON-LISP DO (SEND EVERYONE :THIS-MESSAGE))
∂15-Aug-83 2305 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN Things to do
Received: from MIT-MC by SU-AI with TCP/SMTP; 15 Aug 83 23:05:47 PDT
Received: from SCRC-YAMASKA by SCRC-TENEX with CHAOS; Tue 16-Aug-83 02:01:39-EDT
Date: Tuesday, 16 August 1983, 01:56-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Things to do
To: Scott E. Fahlman <Fahlman%CMU-CS-C@SU-DSN>
Cc: common-lisp@SU-AI
In-reply-to: The message of 14 Aug 83 15:16-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I think we plan to contribute to this, but I at least will not have time to
get near this stuff for at least a couple of months.
3. Portable flavor system / white-pages message-passing substrate.
I think we will find one or more people at Symbolics interested in finishing
the proposal HIC made long ago and implementing it on our machines.
4. LOOP and LetS
We should have both of these available in Common Lisp, and both of them should
be reimplemented. I've intended for almost two years now to do this for LOOP,
so you know how much to believe me when I say I will get back to this soon.
As CL implementations become available at MIT in a few months someone will
no doubt be found to fix LetS.
5. Pretty-printing
DLW is interested in rewriting Waters' GPRINT. I'll let him speak for himself
on what the status of this is.
6. Taxonomic event handling.
I have a proposal for this, which is suffiently abstract that it could be
implemented on something other than flavors (although clearly the right substrate
for it is flavors). The proposal is not at all finished, but I will send it
out in a couple of months.
8. Macro-writer's aids.
I have most of this stuff, written in something pretty close to straight Common Lisp.
The one thing I don't have is type-analysis, although I expect that would be
easy to build on top of the other tools. In a couple of months I'll see about
making this stuff portable and available.
To add to your list:
A portable interpreted-code stepper that uses *EVALHOOK* and *APPLYHOOK*.
A portable or near-portable TRACE package.
A variety of macro memoization schemes, using *MACROEXPAND-HOOK*.
These aren't as trivial as they seem at first blush.
More general destructuring facilities (I have an unfinished proposal).
A portable defstruct implemementation.
Portable floating-point read and print.
∂15-Aug-83 2342 FAHLMAN@CMU-CS-C.ARPA Things to do
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 15 Aug 83 23:42:04 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 16 Aug 83 02:42:18-EDT
Date: Tue, 16 Aug 1983 02:42 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Things to do
In-reply-to: Msg of 16 Aug 1983 01:56-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC at SU-DSN>
Dave,
Glad to hear that you folks are interested in doing a number of things
on the list. Nobody is expecting super-quick action on any of this. As
I said, this is just a bit of pre-planning for things to do once our
respective implementations are stable.
Of the things on your shopping list, STEP, TRACE, and DEFSTRUCT are all
working here and could be made portable easily enough. They may not be
hairy enough (or featureful enough) for everyone's taste.
I'll have to look at our floating read and print, but I doubt that they
are easy to make portable.
-- Scott
∂16-Aug-83 0038 @MIT-MC:Cassels@SCRC-TENEX Things to do
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Aug 83 00:38:21 PDT
Received: from SCRC-MENOTOMY by SCRC-TENEX with CHAOS; Tue 16-Aug-83 03:35:30-EDT
Date: Tuesday, 16 August 1983, 03:35-EDT
From: Robert A. Cassels <Cassels at SCRC-TENEX>
Subject: Things to do
To: Fahlman at CMU-CS-C.ARPA, Moon%SCRC-TENEX%MIT-MC at SU-DSN.ARPA
Cc: common-lisp at SU-AI.ARPA
In-reply-to: The message of 16 Aug 83 02:42-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Tue, 16 Aug 1983 02:42 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
I'll have to look at our floating read and print, but I doubt that they
are easy to make portable.
Ours can be made portable without too much trouble (at some loss of
efficiency). It probably wants a few extra features. I figured I'd
wait for Steele's, in the hope that he's figured out more elegant
solutions to the problems than I did.
∂16-Aug-83 2131 @MIT-MC:HIC@SCRC-TENEX Things to do
Received: from MIT-MC by SU-AI with TCP/SMTP; 16 Aug 83 21:31:41 PDT
Received: from SCH-STYX by SCRC-TENEX with CHAOS; Wed 17-Aug-83 00:25:26-EDT
Date: Tuesday, 16 August 1983, 21:30-PDT
From: Howard I. Cannon <HIC at SCRC-TENEX>
Subject: Things to do
To: Fahlman at CMU-CS-C.ARPA
Cc: common-lisp at SU-AI.ARPA
In-reply-to: The message of 14 Aug 83 12:16-PDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
3. At one point HIC offered to propose a minimal set of white-pages
support for efficient implementation of a portable flavor system, and to
supply the portable part. The white-pages support would also be usable
by other object-oriented paradigms with different inheritance schemes
(that's the controversial part). After a brief exchange of messages,
HIC got super-busy on other matters and we haven't heard much since
then. Either HIC or someone else needs to finish this proposal, so that
we can put in the low-level support and begin playing with the portable
implementation of flavors. Only after more Common Lisp users have had
some opportunity to play with flavors will it make sense to consider
including them (or some variation) in the white pages. There is a lot
of interest in this out in user-land.
My schedule is too unpredictable at this point to make a comitment, but
I intend to be doing some new development on Flavors this fall, and can
likely finish up a reasonable proposal within the next few months. If
there's a 90% chance I can get something through, then I'll schedule
it...
∂16-Aug-83 2324 HEDRICK@RUTGERS.ARPA Re: Things to do
Received: from RUTGERS by SU-AI with TCP/SMTP; 16 Aug 83 23:24:15 PDT
Date: 17 Aug 83 00:43:32 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Things to do
To: HIC%SCRC-TENEX@MIT-MC.ARPA
cc: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Howard I. Cannon <HIC at SCRC-TENEX>" of 17 Aug 83 00:36:25 EDT
An alternative might be
movei n,2
pushj p,@[fadr block]
where the address in the fadr block was indexed by N. That would still
save testing and dispatching within the function itself, but would
avoid adding 4 words to the FADR block. What do you think?
-------
∂17-Aug-83 0848 @MIT-MC:DLW%SCRC-TENEX%MIT-MC@SU-DSN Re: Things to do
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Aug 83 08:48:03 PDT
Date: 17 Aug 1983 1049-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: Re: Things to do
To: Moon%SCRC-TENEX%MIT-MC@SU-DSN
cc: Fahlman%CMU-CS-C@SU-DSN, common-lisp@SU-AI
In-Reply-To: The message of Tuesday, 16 August 1983, 01:56-EDT from David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
I have done 90% of the work of rewriting GPRINT completely in
modern Lisp style, which also makes it perform
better. I still have to do the "last 10%" with all that that
implies. Converting it to Common Lisp also has to be done
but it clearly easy. I don't think when I'll have time to work on this
more, though. Keep in touch.
-------
∂18-Aug-83 1006 @MIT-MC:benson@SCRC-TENEX What to do next
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83 10:06:04 PDT
Date: Thursday, 18 August 1983 11:54-EDT
From: dlw at SCRC-TENEX, benson at SCRC-TENEX
Subject: What to do next
To: fahlman at cmuc
Cc: common-lisp at su-ai
Scott, I appreciated your summary of pending issues in Common Lisp, and
I certainly think we should proceed to work on these things. However, I
think that the "next things to do", after we get out the initial real
Common Lisp manual, are:
(1) Create a Common Lisp Virtual Machine specification, and gather a
body of public domain Lisp code which, when loaded into a proto-Lisp
that meets the spec, produces a complete Common Lisp interpreter that
meets the full language spec. (This doesn't address the portable
compiler problem.)
(2) Establish an official Common Lisp subset, suitable for
implementation on 16-bit microcomputers such as the 68000 and the 8088.
I understand that Gabriel is interested in 68000 implementations, and I
am trying to interest Bob Rorscharch (who implemented IQLISP, which is
an IBM PC implementation of a UCILISP subset) in converting his product
into a Common Lisp implementation.
There are a lot of problems with subsetting. You can't leave out
multiple values, beacuse several primitives return multiple values and
you don't want to omit all of these primitives (and you don't want to
discourage the addition of new primitives that return multiple values,
in future versions of Common Lisp). You can't leave out packages, at
least not entirely, because keywords are essential to many functions.
And many things, if removed, would have to be replaced by something
significantly less clean. We'd ideally like to remove things that (a)
can be removed without creating the need for an unclean simpler
substitute, and (b) aren't used by the rest of the system. In other
words, we have to find modular chunks to break off. And, of course,
any problem that works in the subset has to work and do exactly the
same thing in full Common Lisp, unless the program has some error
(in the "it is an error" sense). The decision as to what goes
in and what goes out should be made in light of the fact that
an implementation might be heavily into "autoloading".
Complex numbers can easily be omitted.
The requirement for all the floating point precisions can be
omitted. Of course, Common Lisp is flexiable in this regard anyway.
Rational numbers could be left out. They aren't hard, per se, but
they're just another thing to do. The "/" function on two integers
would have to signal an error.
Packages could be trimmed down to only be a feature that supplies
keywords; most of the package system might be removable.
Lexical scoping might possibly be removable. You could remove support
for LABELS, FLET, and MACROLET. You can't remove internal functions
entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
might have some restrictions on them.
Adjustable arrays could be removed. Fill pointers could go too,
although it's not clear that it's worth it. In the extreme, you could
only have simple arrays. You could even remove multi-D arrays
entirely, or only 1-D and 2-D.
Several functions look like they might be big, and aren't really
required. Some candidates: COERCE, TYPE-OF, the hard version
of DEFSETF (whatever you call it), LOOP,
TYPEP and SUBTYPEP are hard to do, but it's hard to see how
to get rid of the typing system! SUBTYPEP itself might go.
Multiple values would be a great thing to get rid of in the subset, but
there are the Common Lisp primitives that use multiple values. Perhaps
we should add new primitives that return these second values only, for
the benefit of the subset, or something.
Catch, throw, and unwind-protect could be removed, although they're
sure hard to live without.
Lots of numeric stuff is non-critical: GCD, LCM, CONJUGATE, the
exponentials and trascendentals, rationalize, byte manipulation, random
numbers.
The sequence functions are a lot of work and take a lot of room in your
machine. It would be nice to do something about this. Unfortunately,
simply omitting all the sequence functions takes away valuable basic
functionality such as MEMQ. Perhaps the subset could leave out some of
the keywords, like :test and :test-not and :from-end.
Hash tables are not strictly necessary, although the system itself
are likely to want to use some kind of hash tables somewhere,
maybe not the user-visible ones.
Maybe some of the defstruct options could be omitted, though I don't
think that getting rid of defstruct entirely would be acceptable.
Some of the make-xxx-stream functions are unnecessary.
Some of the hairy reader syntax is not strictly necessary. The circular
structure stuff and load-time evaluation are the main candidates.
The stuff to allow manipulation of readtables is not strictly necessary,
or could be partially restricted.
Some of the hairy format options could be omitted. I won't go into
detail on this.
Some of the hairy OPEN options could go, although I'd hate to be the one
to decide which options are the non-critical ones. Also some of the
file operations (rename, delete, attribute manipulation) could go.
The debugging tools might be optional although probably they just
get autoloaded anyway.
∂18-Aug-83 1134 @MIT-MC:MOON@SCRC-TENEX subsetting
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83 11:33:52 PDT
Date: Thursday, 18 August 1983 14:26-EDT
From: MOON at SCRC-TENEX
To: dlw at SCRC-TENEX, benson at SCRC-TENEX
Cc: common-lisp at su-ai
Subject: subsetting
In-reply-to: The message of 18 Aug 1983 11:54-EDT from dlw at SCRC-TENEX, benson at SCRC-TENEX
Most (by no means all) of the things you suggest omitting are quite inexpensive
to include in an implementation that is optimized for space rather than speed.
I don't think it is a good idea to have something called "Common Lisp" that
omits large portions of the language. All the special forms should be included.
Two good ways to fit into a smaller machine without sacraficing functionality
are to use "autoloading" for little-used functions and to not include things
only needed at compile time in the run-time environment (they can be "autoloaded"
when needed for debugging or interpretive execution, of course). I think both
of these categories are probably very large in Common Lisp.
∂18-Aug-83 1226 HEDRICK@RUTGERS.ARPA Re: subsetting
Received: from RUTGERS by SU-AI with TCP/SMTP; 18 Aug 83 12:26:45 PDT
Date: 18 Aug 83 15:23:50 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: subsetting
To: MOON%SCRC-TENEX@MIT-MC.ARPA
cc: dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: Message from "MOON at SCRC-TENEX" of 18 Aug 83 14:26:00 EDT
Another approach is to use byte code instead of real machine code.
This can allow a significant space saving.
-------
∂18-Aug-83 1224 HEDRICK@RUTGERS.ARPA Re: What to do next
Received: from RUTGERS by SU-AI with TCP/SMTP; 18 Aug 83 12:24:32 PDT
Date: 18 Aug 83 15:20:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: What to do next
To: dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA
cc: fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: Message from "dlw at SCRC-TENEX, benson at SCRC-TENEX" of 18 Aug 83 11:54:00 EDT
In general I agree with you. However let me point out:
1) that you can simplify MV's to the point that implementation is
trivial. All you have to do is require that the caller of a function
never asks for more MV's than there really are. (In particular, that
he never asks for MV's when there aren't any.) This handles the most
useful cases. Certainly it handles the case of calling system functions
that return MV's. Then you require only a couple of primitives,
probably MV-SETQ and MV-BIND. You certainly do not do MV-LIST (because
you can't) nor MV-CALL. The result is that you can implement MV's
by putting the values in the AC's or in global variables. No
additional mechanisms are needed. I believe this is the right thing
to have done in the first place. (Indeed I think the whole subset
is probably going to be more useful than the real language.)
2) we do have a compiler that is probably about as portable as
you are going to get. We use CMU's Spice Lisp compiler. It produces
code for a stack-oriented microcoded machine. We transform this
into code for a register-oriented machine. The instruction set we
use is an extended version of Utah's CMACS, the final intermediate
representation used in PSL. It is close enough to machine code that
we produce the actual machine code in LAP. I am sure there ae
machines that we might have trouble with, but for the ones I am
used to, a couple of days playing with LAP should allow our code to
be loaded on any register-oriented machine. The origial Spice Lap
code could probably be loaded on any stack-oriented machine.
-------
∂18-Aug-83 1221 FAHLMAN@CMU-CS-C.ARPA What to do next
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Aug 83 12:20:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 18 Aug 83 15:21:42-EDT
Date: Thu, 18 Aug 1983 15:21 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: dlw%SCRC-TENEX@MIT-MC.ARPA, benson%SCRC-TENEX@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: What to do next
In-reply-to: Msg of 18 Aug 1983 11:54-EDT from dlw at SCRC-TENEX, benson at SCRC-TENEX
Date: Thursday, 18 August 1983 11:54-EDT
(1) Create a Common Lisp Virtual Machine specification, and gather a
body of public domain Lisp code which, when loaded into a proto-Lisp
that meets the spec, produces a complete Common Lisp interpreter that
meets the full language spec. (This doesn't address the portable
compiler problem.)
Our Spice Lisp implementation is currently serving exactly this need for
about 6 implementation efforts. Instead of specifying a little Lisp kernel
that has to be implemented, we specify a byte-coded instruction set,
then provide Common Lisp written in Common Lisp (with some of these
byte-coded primitives sprinkled in), plus a compiler written in Common
Lisp that produces these byte codes. All a prospective user has to
supply are either microcode for the byte-codes or a post-processor from
byte codes to their machine's native instruction set, plus the byte-code
primitives, GC, I/O, and the system interface stuff. Of course, once
that is done, it is worth putting about a man-year of tuning into any
given implementation to make it run as well as possible.
So our SLGUTS document, along with our public-domain Lisp code and
compiler, do most of what the blue pages are supposed to do. We are
currently polishing our system up so that it is legal, and in the
process we are cleaning up our compiler so that it will be easier to
replace the whole code-generator, if people would rather do that than
work from byte-codes. We also plan a substantial cleanup on our
byte-code set, which is by now quite obsolete and creaky.
The next obvious step is to take all of this and turn it into a cleanly
packaged "implementor's kit". That would reduce the amount of
hand-holding we would have to do and make the whole thing look more
portable. I don't have much interest in taking this additional (largely
cosmetic) step, but would cooperate with anyone else who wants to do it.
Of course, if someone wants to build a better compiler/kit (ours is more
stack-oriented than is optimal on conventional architectures and does
not have all those hairy optimizations in it that real compiler hackers
love), that would be a good thing to do.
So I guess I see this as a mostly-solved problem and therefore not a
high-priority issue.
(2) Establish an official Common Lisp subset, suitable for
implementation on 16-bit microcomputers such as the 68000 and the 8088.
I'm a little dubious about this subsetting business. It is true that
one could get rid of maybe half the virtual core image by judicious
trimming, though including a compiler or Hemlockish editor would push
you back up there. Rather than worry a lot about trimming the Lisp and
about going from a big core image to autoload, maybe the time should be
spent figuring out how to fake a decent virtual memory system on these
machines. It would be nice to have things like Format lurking out on
the floppies but virtually there, rather than gone but autoloadable.
A whole generation of people learned to hate Lisp because they tried to
prehistoric implementations without good debugging tools,
pretty-printing editors,and the other things that make Lisp a decent
programming environment. Let's not repeat this and expose high-school
kids to the result.
One thing we might do, if we want Common Lisp programs to be deliverable
on micros with the minimum of memory, is to work on a system that goes
over a set of compiled files and builds a Lisp core image with only
these things and the Lisp facilities that they call included. You would
develop on your Vax or 3600, but the turnkey expert system might then
run on a 68000-based machine with minimal disk.
Anyway, to respond to your suggestions:
Complex numbers can easily be omitted.
[ Yep. Should ahve been omitted from the real thing, and may still be
if nobody works up the enthusiasm to implement them.]
The requirement for all the floating point precisions can be
omitted. Of course, Common Lisp is flexiable in this regard anyway.
[ Yeah. The high-school version could leave them out altogether, and
all the trascendental functions, for a big saving. ]
Rational numbers could be left out. They aren't hard, per se, but
they're just another thing to do. The "/" function on two integers
would have to signal an error.
[ This wouldn't save much -- GCD is all you need and that's not too big.
Maybe leave out the Float/rational conversions.]
Packages could be trimmed down to only be a feature that supplies
keywords; most of the package system might be removable.
[ Yeah. Again it doesn't save much. ]
Lexical scoping might possibly be removable. You could remove support
for LABELS, FLET, and MACROLET. You can't remove internal functions
entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
might have some restrictions on them.
[ Lexical scoping doesn't cost much in space, but it slows down the
interpreter and adds much hair to the compiler. If you want to save on
compiler space, let GO and RETURN be confined in the traditional way
(only to a cleanly surrounding block and not from a position that leaves
crud on the stack) and eliminate lexical closures and the FLET stuff.]
Adjustable arrays could be removed. Fill pointers could go too,
although it's not clear that it's worth it. In the extreme, you could
only have simple arrays. You could even remove multi-D arrays
entirely, or only 1-D and 2-D.
[ This would save a fair amound in dispatching hair. Not trying to
super-optimize for speed would also save a lot of space -- whether
that's a good trade depends on the machine and the applications.]
Several functions look like they might be big, and aren't really
required. Some candidates: COERCE, TYPE-OF, the hard version
of DEFSETF (whatever you call it), LOOP,
[Yup.]
TYPEP and SUBTYPEP are hard to do, but it's hard to see how
to get rid of the typing system! SUBTYPEP itself might go.
[Got to have TYPEP, but not the hairy compund types and booleans.
Subtypep is needed by the compiler but not much by user code.]
Multiple values would be a great thing to get rid of in the subset, but
there are the Common Lisp primitives that use multiple values. Perhaps
we should add new primitives that return these second values only, for
the benefit of the subset, or something.
[If you're willing to cons when passing back multiples, or to limit the
number to, say, 3 values, it becomes easy to do. I believe that only
our unfortunate time functions return more than a few values.]
Catch, throw, and unwind-protect could be removed, although they're
sure hard to live without.
[No, you've got to keep these. They become easy to do if you don't have
to pass multiple back on the stack.]
Lots of numeric stuff is non-critical: GCD, LCM, CONJUGATE, the
exponentials and trascendentals, rationalize, byte manipulation, random
numbers.
[Leave in hyperbolic arctan, though -- every language needs at least one
function that nobody has ever tried.]
The sequence functions are a lot of work and take a lot of room in your
machine. It would be nice to do something about this. Unfortunately,
simply omitting all the sequence functions takes away valuable basic
functionality such as MEMQ. Perhaps the subset could leave out some of
the keywords, like :test and :test-not and :from-end.
[Again, these are simple if you're willing to do everything with ELT and
FUNCALL and are not going for tenseness. It is checking for 53 special
cases that blow things up. If you don't have them in, people will write
DO's and their code will balloon.]
Hash tables are not strictly necessary, although the system itself
are likely to want to use some kind of hash tables somewhere,
maybe not the user-visible ones.
[Again, if you want tiny but slow, an A-list can do anything a
hash-table can.]
Maybe some of the defstruct options could be omitted, though I don't
think that getting rid of defstruct entirely would be acceptable.
Some of the make-xxx-stream functions are unnecessary.
Some of the hairy reader syntax is not strictly necessary. The circular
structure stuff and load-time evaluation are the main candidates.
The stuff to allow manipulation of readtables is not strictly necessary,
or could be partially restricted.
Some of the hairy format options could be omitted. I won't go into
detail on this.
Some of the hairy OPEN options could go, although I'd hate to be the one
to decide which options are the non-critical ones. Also some of the
file operations (rename, delete, attribute manipulation) could go.
[All of the above sounds OK.]
The debugging tools might be optional although probably they just
get autoloaded anyway.
[For an educational system on cheap machines, you don't skimp here. For
a delivery vehicle, you don't need these.]
∂18-Aug-83 1349 @MIT-MC:MOON@SCRC-TENEX subsetting
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83 13:49:26 PDT
Date: Thursday, 18 August 1983 16:40-EDT
From: MOON at SCRC-TENEX
To: common-lisp at sail
Subject: subsetting
One last comment. Inexpensive machines with ~ 1 megabyte main memory,
~ 40-80 megabyte disk, and VAX-class processors will be here sooner
than we think. They may be limited by software and marketing more than
by technology. So maybe by the time a subset was defined there wouldn't
be much demand for it.
∂18-Aug-83 1352 @MIT-MC:benson@SCRC-TENEX What to do next
Received: from MIT-MC by SU-AI with TCP/SMTP; 18 Aug 83 10:06:04 PDT
Date: Thursday, 18 August 1983 11:54-EDT
From: dlw at SCRC-TENEX, benson at SCRC-TENEX
Subject: What to do next
To: fahlman at cmuc
Cc: common-lisp at su-ai
Scott, I appreciated your summary of pending issues in Common Lisp, and
I certainly think we should proceed to work on these things. However, I
think that the "next things to do", after we get out the initial real
Common Lisp manual, are:
(1) Create a Common Lisp Virtual Machine specification, and gather a
body of public domain Lisp code which, when loaded into a proto-Lisp
that meets the spec, produces a complete Common Lisp interpreter that
meets the full language spec. (This doesn't address the portable
compiler problem.)
(2) Establish an official Common Lisp subset, suitable for
implementation on 16-bit microcomputers such as the 68000 and the 8088.
I understand that Gabriel is interested in 68000 implementations, and I
am trying to interest Bob Rorscharch (who implemented IQLISP, which is
an IBM PC implementation of a UCILISP subset) in converting his product
into a Common Lisp implementation.
There are a lot of problems with subsetting. You can't leave out
multiple values, beacuse several primitives return multiple values and
you don't want to omit all of these primitives (and you don't want to
discourage the addition of new primitives that return multiple values,
in future versions of Common Lisp). You can't leave out packages, at
least not entirely, because keywords are essential to many functions.
And many things, if removed, would have to be replaced by something
significantly less clean. We'd ideally like to remove things that (a)
can be removed without creating the need for an unclean simpler
substitute, and (b) aren't used by the rest of the system. In other
words, we have to find modular chunks to break off. And, of course,
any problem that works in the subset has to work and do exactly the
same thing in full Common Lisp, unless the program has some error
(in the "it is an error" sense). The decision as to what goes
in and what goes out should be made in light of the fact that
an implementation might be heavily into "autoloading".
Complex numbers can easily be omitted.
The requirement for all the floating point precisions can be
omitted. Of course, Common Lisp is flexiable in this regard anyway.
Rational numbers could be left out. They aren't hard, per se, but
they're just another thing to do. The "/" function on two integers
would have to signal an error.
Packages could be trimmed down to only be a feature that supplies
keywords; most of the package system might be removable.
Lexical scoping might possibly be removable. You could remove support
for LABELS, FLET, and MACROLET. You can't remove internal functions
entirely (i.e. MAPCAR of a lambda-expression can't be removed) but they
might have some restrictions on them.
Adjustable arrays could be removed. Fill pointers could go too,
although it's not clear that it's worth it. In the extreme, you could
only have simple arrays. You could even remove multi-D arrays
entirely, or only 1-D and 2-D.
Several functions look like they might be big, and aren't really
required. Some candidates: COERCE, TYPE-OF, the hard version
of DEFSETF (whatever you call it), LOOP,
TYPEP and SUBTYPEP are hard to do, but it's hard to see how
to get rid of the typing system! SUBTYPEP itself might go.
Multiple values would be a great thing to get rid of in the subset, but
there are the Common Lisp primitives that use multiple values. Perhaps
we should add new primitives that return these second values only, for
the benefit of the subset, or something.
Catch, throw, and unwind-protect could be removed, although they're
sure hard to live without.
Lots of numeric stuff is non-critical: GCD, LCM, CONJUGATE, the
exponentials and trascendentals, rationalize, byte manipulation, random
numbers.
The sequence functions are a lot of work and take a lot of room in your
machine. It would be nice to do something about this. Unfortunately,
simply omitting all the sequence functions takes away valuable basic
functionality such as MEMQ. Perhaps the subset could leave out some of
the keywords, like :test and :test-not and :from-end.
Hash tables are not strictly necessary, although the system itself
are likely to want to use some kind of hash tables somewhere,
maybe not the user-visible ones.
Maybe some of the defstruct options could be omitted, though I don't
think that getting rid of defstruct entirely would be acceptable.
Some of the make-xxx-stream functions are unnecessary.
Some of the hairy reader syntax is not strictly necessary. The circular
structure stuff and load-time evaluation are the main candidates.
The stuff to allow manipulation of readtables is not strictly necessary,
or could be partially restricted.
Some of the hairy format options could be omitted. I won't go into
detail on this.
Some of the hairy OPEN options could go, although I'd hate to be the one
to decide which options are the non-critical ones. Also some of the
file operations (rename, delete, attribute manipulation) could go.
The debugging tools might be optional although probably they just
get autoloaded anyway.
∂17-Sep-83 1809 GSB@MIT-ML implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 17 Sep 83 18:09:47 PDT
Date: 17 September 1983 21:12 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: implied contracts in the mapping functions?
To: common-lisp @ SU-AI
I would appreciate comments on the following "bug report" i just
received.
----------------
Date: 17 Sep 83 11:59-EST (Sat)
Subject: bug in mapc
To: bug-nil@mit-mc
I am iterating over a list and simultaneously adding things to the end of
the list with NCONC. It works fine until I get down to the final iteration.
If I then NCONC something on to the end of the list, MAPC exits without
looking at the newly added list elements.
. . .
----------------
The manual neither implies that this should work, nor that it might not.
My impression on this is that using a mapping function is inappropriate
here, and the (unintentional) optimization which causes his case to fail
is allowable with the mapping functions. On the other hand, since it is
so likely for this to actually work (i bet it does in most other
implementations, and in fact it only fails in NIL in the interpreter when
there is exactly one list argument to the MAPC, MAPCAN, and MAPCAR), it
may not be worth the conceptual overhead to disallow this sort of hacking
when it seems so "obvious" that it should work.
∂17-Sep-83 1821 FAHLMAN@CMU-CS-C.ARPA implied contracts in the mapping functions?
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 17 Sep 83 18:21:31 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 17 Sep 83 21:23:50-EDT
Date: Sat, 17 Sep 1983 21:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Glenn S. Burke <GSB@MIT-ML.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: implied contracts in the mapping functions?
In-reply-to: Msg of 17 Sep 1983 21:12 EDT from Glenn S. Burke <GSB at MIT-ML>
I think that "it is an error" to destructively mess around with a list
after it has been fed to MAPCAR or even to DOLIST. The fact that most
implementations would do this in a certain way and the user can guess
what that way is should not matter. If we let people twiddle hidden
state and count on the results, there will be no safe optimizations
left, and all Common Lisp implementations will slow down by a
considerable factor.
-- Scott
∂17-Sep-83 2011 @MIT-MC:Cassels%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
Received: from MIT-MC by SU-AI with TCP/SMTP; 17 Sep 83 20:10:11 PDT
Received: from SCRC-MUDDY by SCRC-TENEX with CHAOS; Sat 17-Sep-83 23:09:56-EDT
Date: Saturday, 17 September 1983, 23:08-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX@MIT-MC>
Subject: implied contracts in the mapping functions?
To: Fahlman@CMU-CS-C, GSB@MIT-ML
Cc: common-lisp@SU-AI
In-reply-to: The message of 17 Sep 83 21:23-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sat, 17 Sep 1983 21:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
I think that "it is an error" to destructively mess around with a list
after it has been fed to MAPCAR or even to DOLIST. The fact that most
implementations would do this in a certain way and the user can guess
what that way is should not matter. If we let people twiddle hidden
state and count on the results, there will be no safe optimizations
left, and all Common Lisp implementations will slow down by a
considerable factor.
I agree that it ought to be "an error" or left undefined
(implementation-dependent). Other languages with looping constructs
have run into this problem, and most have decided to admit that there is
"hidden state" which is implementation-dependent.
∂18-Sep-83 1624 @MIT-ML:Moon%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 18 Sep 83 16:24:05 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sun 18-Sep-83 19:12:49-EDT
Date: Sunday, 18 September 1983, 18:47-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: implied contracts in the mapping functions?
To: Glenn S. Burke <GSB@MIT-ML>
Cc: common-lisp@SU-AI
In-reply-to: The message of 17 Sep 83 21:12-EDT from Glenn S. Burke <GSB at ML>
Date: 17 September 1983 21:12 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
I would appreciate comments on the following "bug report" i just
received.
I am iterating over a list and simultaneously adding things to the end of
the list with NCONC. It works fine until I get down to the final iteration.
I don't think the language should define what happens in this case (even though
it "works" in my implementation, as it happens). Such iterations should be
written in terms of lower-level primitives, such as DO or TAGBODY+SETQ.
∂18-Sep-83 1732 @MIT-ML,@MIT-MC:kmp@MIT-MC implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 18 Sep 83 17:32:09 PDT
Date: Sunday, 18 September 1983, 19:50-EDT
From: Kent M. Pitman <kmp at MIT-MC>
Subject: implied contracts in the mapping functions?
To: Cassels at SCRC-TENEX, "Fahlman%CMU-CS-C" at MIT-ML
Cc: "Common-Lisp%SAIL" at MIT-ML
In-reply-to: The message of 17 Sep 83 23:08-EDT from Robert A. Cassels <Cassels%SCRC-TENEX at MIT-MC>,
The message of 17 Sep 83 21:23-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 17 Sep 83 21:12-EDT from Glenn S. Burke <GSB at MIT-ML>
Date: Saturday, 17 September 1983, 23:08-EDT
From: Robert A. Cassels <Cassels%SCRC-TENEX@MIT-MC>
Date: Sat, 17 Sep 1983 21:23 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
I think that "it is an error" to destructively mess around with a list
after it has been fed to MAPCAR or even to DOLIST. The fact that most
implementations would do this in a certain way and the user can guess
what that way is should not matter. If we let people twiddle hidden
state and count on the results, there will be no safe optimizations
left, and all Common Lisp implementations will slow down by a
considerable factor.
I agree that it ought to be "an error" or left undefined
(implementation-dependent). Other languages with looping constructs
have run into this problem, and most have decided to admit that there is
"hidden state" which is implementation-dependent.
I disagree.
Arguments that other languages do x or y prove nothing. Many other languages
are just plain afraid of anything. Or they may have sufficiently different data
structures and types that this is reasonable. I'd want concrete examples of
design criteria from specific languages before buying a follow-the-leader
argument.
Vague arguments about possible optimizations are also a bad idea. I would
like to hear such arguments. Generally, I would like to see optimizations
shaped by linguistic considerations, not linguistic considerations shaped
by optimizations. Certainly without specific examples of the kinds of
optimizations you want to make, how can I understand the consequences of
those optimizations...
While programmers are prone to occassional errors in judgment,
I think it is important to recognize systematic "errors" that they make and
ask why they make them. For example, it was never a documented feature of
APPEND that it would copy its first N arguments, but people still used to
write (APPEND x NIL) to cause copying to happen. There is the small issue of
whether the program was going to do
(IF (NULL Y) X) (REALLY-APPEND X Y))
because that would screw them but that was their only `real' error. The other
assumption (that REALLY-APPEND would really copy X) was not really just
an assumption; it was pretty much forced by the contract of APPEND. So it
isn't as unsafe as it looks at first glance. Likewise, I think, for MAPCAR,
etc. The bug GSB mentioned was one where the guy lost because he let the
NCONC get too close to the point you were scanning with the map, but the
basic theory that you could bash something farther down the line was sound.
Now in the case of (APPEND x NIL), people got smart and just made
a subroutine, COPYLIST, for what really needed to be done. But in the case of
this NCONCing onto lists that are being mapped, I don't really think we can
package it quite so simply...
Also, I don't think it is ever an ERROR (signalled or otherwise) for a
user to modify later structure. At worst, it should be nondeterministic with
respect to the algorithm. I could imagine a case with mapping down a list of
integers numbers which you are simulataneously NCONCing with new integers and
splicing non-primes out of and using as a sieve where it might actually be
reasonable to not worry whether the mapping operator actually noticed the
splice. In one case, it might take slightly longer because more numbers might
be tested than were really necessary, but in the case I'm thinking of, it
would not and should not affect the correctness of the algorithm and the
programmer shouldn't take grief from other programmers about how it was an
"error" to think that way.
And I really think that there may be cases where efficiency considerations
may call for me to write something which has a tail which is known
to be more than a threshold distance from the list which is being mapped. I
only think we should even say it is undefined for the programmer to try to
modify the current cell (ie, if I am looking at the D in (A B C D), I should
not expect that NCONCing the list would matter), but I think it is reasonable
for a programmer to assume that if he's looking at the C, that the list can be
NCONC'd. This is important to the Lisp programmer's view of lists as
modifiable, shared structure. I think we should carefully define the unusual
situations, but I think it's overly restrictive to really define that
modifying any part of the list after the part under inspection is an error...
One side light -- Any system with multi-processing is fairly likely at one
time or another to have GET going on in one process while PUTPROP is going
on in another process for the same symbol -- perhaps not for the same indicator.
We surely don't want people claiming this is erroneous and that we need to
lock property lists since for most applications, the programmer will (at
least should) hand-lock any cases that matter and the rest should just take
what comes.
∂18-Sep-83 2158 FAHLMAN@CMU-CS-C.ARPA implied contracts in the mapping functions?
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 18 Sep 83 21:57:53 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 19 Sep 83 01:00:28-EDT
Date: Mon, 19 Sep 1983 01:00 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Kent M. Pitman <kmp@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: implied contracts in the mapping functions?
In-reply-to: Msg of 18 Sep 1983 19:50-EDT from Kent M. Pitman <kmp at MIT-MC>
Vague arguments about possible optimizations are also a bad idea.
I disagree. It should be clear that this sort of thing rules out a very
large class of possible optimizations -- basically, all those
optimizations that would depend on some property of the input list, such
as its length or the type of elements present. If we allow the user's
functionals to mutilate this list after it is passed in, any highly
optimizing compiler would have to check these functionals for destructive
side-effects on the list, a much more difficult task in most cases.
Generally, I would like to see optimizations
shaped by linguistic considerations, not linguistic considerations shaped
by optimizations.
OK, how about the following: When you pass an object to a Common Lisp
function or special form whose job it is to process that object in some
coherent manner, it HAS to be undefined what happens if you somehow
regain control (perhaps because the form is executing a function on your
behalf) and destructively modify that object in the middle of the
operation. I see no way to make this coherent in general. Therefore to
allow a few simple cases of it (chewing only on the as-yet-unprocessed
tail of a list being chewed linearly) would be an ugly hack.
Multi-processing is not addressed by the Common Lisp design and trying
to imagine what it would look and use that as a basis for argument seems
much more bizarre to me than worrying about what "vague optimizations"
some future super-compiler for the existing language would want to
employ.
-- Scott
∂19-Sep-83 0335 DDYER@USC-ISIB "optimizations"
Received: from USC-ISIB by SU-AI with TCP/SMTP; 19 Sep 83 03:35:19 PDT
Date: 19 Sep 1983 0331-PDT
Subject: "optimizations"
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: common-lisp@SU-AI.ARPA
I agree strongly that vague arguments about optimizatons are
a bad idea. The only optimizations permitted should be those
proven to not affect the semantics of the program. I have seen
too many cases where seemingly harmless optimizations cause
subtle bugs when the user's program does something unusual.
In the current case, mapping functions should certainly be required
to conform to the reasonale expectation of the user that a NCONC
will work. If permitted, this kind of incompatability is
exactly what will make common lisp non-portable. Saving a
cycle or two just isn't worth the dirtyness of explaining
to the user why a NCONC won't always work and what to avoid.
I am reminded of Larry Masinter's golden words:
"I don't believe in portability in the absence of porting"
There should be only ONE implementation of the mapping functions,
written in unambiguous primitives, shared by all common lisp
implementations. Likewise for the largest possible subset of
the core language. This is the best way to make sure that
the zillion+1 small implementation choices one has to make,
even working from the tightest specification, are made the same
way by all the implementations.
-------
∂19-Sep-83 0548 RAM@CMU-CS-C.ARPA Implicit contracts
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 19 Sep 83 05:47:58 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 19 Sep 83 08:50:49-EDT
Date: Mon, 19 Sep 1983 08:50 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Implicit contracts
I think that the specification of a language by implementation as
implied by Dyer's message is an extremely bad idea. If it is legal to
depend on any possible behavior of a function then it becomes
impossible to ever change any function because someone might depend on
a particular idiosyncratic behavior.
It seems to me that the best approach in Common Lisp is to have
that manual describe every important behavior of an operation, and for
any code which depends on something not guaranteed by the manual to be
considered erroneous.
As far as assuring agreement with the manual, I think that the
best solution would be to have a comprehensive validation suite, or
lacking that, a number of large portable applications.
Rob
∂19-Sep-83 0811 @MIT-MC:BSG%SCRC-TENEX@MIT-MC "optimizations"
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Sep 83 08:11:49 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 19-Sep-83 11:08:25-EDT
Date: Monday, 19 September 1983, 11:07-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: "optimizations"
To: DDYER@USC-ISIB, common-lisp@SU-AI
In-reply-to: The message of 19 Sep 83 06:31-EDT from Dave Dyer <DDYER at USC-ISIB>
Date: 19 Sep 1983 0331-PDT
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
There should be only ONE implementation of the mapping functions,
written in unambiguous primitives, shared by all common lisp
implementations. Likewise for the largest possible subset of
the core language. This is the best way to make sure that
the zillion+1 small implementation choices one has to make,
even working from the tightest specification, are made the same
way by all the implementations.
I disagree with this view fairly strongly. Different implementations
have different instruction sets and primitives, and what appears to
be an optimal macro expansion for one implementation is often not so
for another. It is best to specify the contracts of one of these goddamn
things by documentation, driven from need of what problem the function
or form at hand was supposed to solve, not by code that nails its implementation
so that you can find delightful and challenging ways to undercut
its intended purpose.
∂19-Sep-83 1231 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Implicit contracts
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Sep 83 12:31:33 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 19-Sep-83 15:24:45-EDT
Date: Monday, 19 September 1983, 15:23-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Implicit contracts
To: Rob MacLachlan <RAM@CMU-CS-C>
Cc: common-lisp@SU-AI
In-reply-to: The message of 19 Sep 83 08:50-EDT from Rob MacLachlan <RAM at CMU-CS-C>
Date: Mon, 19 Sep 1983 08:50 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
I think that the specification of a language by implementation as
implied by Dyer's message is an extremely bad idea. If it is legal to
depend on any possible behavior of a function then it becomes
impossible to ever change any function because someone might depend on
a particular idiosyncratic behavior.
Precisely the problem that Interlisp has.
It seems to me that the best approach in Common Lisp is to have
that manual describe every important behavior of an operation, and for
any code which depends on something not guaranteed by the manual to be
considered erroneous.
As far as assuring agreement with the manual, I think that the
best solution would be to have a comprehensive validation suite, or
lacking that, a number of large portable applications.
I am in complete agreement with this. We should definitely have a
comprehensive validation suite. Even one that isn't comprehensive
would be helpful. I wrote one for the division-related functions
(/, mod, floor, etc.), but that is hardly a drop in the bucket.
∂19-Sep-83 1307 @MIT-ML:HEDRICK@RUTGERS.ARPA Re: implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 19 Sep 83 13:07:32 PDT
Date: 19 Sep 83 16:07:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: implied contracts in the mapping functions?
To: kmp%MIT-MC@MIT-ML.ARPA
cc: Cassels%SCRC-TENEX@MIT-ML.ARPA, Fahlman%CMU-CS-C@MIT-ML.ARPA,
Common-Lisp%SAIL@MIT-ML.ARPA
In-Reply-To: Message from "Kent M. Pitman <kmp at MIT-MC>" of 18 Sep 83 20:37:17 EDT
It is dangerous to have a feature that obviously ought to be in a
language not be there, or be there in only half the implementations. No
matter what you say in the manual, people will use it where it works.
You should either define what NCONC to a list being mapped does, or
strongly suggest that its use be made an error that is detected. Since
I don't know how to do the latter, I suggest the former.
-------
∂19-Sep-83 1415 DDYER@USC-ISIB Re: "optimizations"
Received: from USC-ISIB by SU-AI with TCP/SMTP; 19 Sep 83 14:15:35 PDT
Date: 19 Sep 1983 1416-PDT
Subject: Re: "optimizations"
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC.ARPA>, DDYER@USC-ISIB.ARPA,
common-lisp@SU-AI.ARPA
In-Reply-To: Your message of Monday, 19 September 1983, 11:07-EDT
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
There should be only ONE implementation of the mapping functions,
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
I disagree with this view fairly strongly. Different implementations
have different instruction sets and primitives, and what appears to
be an optimal macro expansion for one implementation is often not so
for another.
If a different actual implementation is better for some machine, then
the implementor is free to substitute an equivalent one, provided
it is really equivalent. It is exactly the desire to optimize each
implementation at the expense of "minor" incompatability that in aggregate
makes putatively compatable languages incompatable, be it Lisp of Fortran.
I don't really believe that specification by implementation is ideal,
just that it is the only reliable mechanism. No prose specification
can capture the full subtlety of MAPCAR. To be sure, there should be
a prose specification first, and the prose should remain the ultimate
arbiter of what is correct; but ONE program, written to be faithful
to the spec, should be the arbiter of what is an acceptable implementation.
If two implementations of the same specification behave differently
in ways not explicitly permitted by the specification, then at least
one of them is wrong.
The laser edition of the manual states in its description of MAP:
"... The result sequence is as long as the shortest of the input sequences.
If the FUNCTION has side effects, it can count on being called
first with all elements numbered zero, and then on all elements
numbered one and so on. ..."
Now, I can see that the natural behavior when FUNCTION modifies one
of the input sequences will be quite different when the input sequence
is an array verses when it is a list; In fact there are too many to
ennumerate. (examples: an array-type sequence probably has a known
length. Is it legal to assume the length won't change? Mapping over
a list-type sequence is "naturally" unaffected by changes to the elements
already processed, whereas array-type sequences might "naturally" skip
or repeat elements if a new element is removed or added at the beginning.)
Confronted with this variability, the current spec is inadequate. One
extreme position to correct the spec would be to make it read:
"Side effects which change the number of elements in a sequence
have unpredictable effects on the execution sequence."
Which would simply define a large grey area. An opposite extreme might read
"Side effects which change the number of elements in a sequence
are immediately effective; The N'th call to the user's function
will be with the elements which are N'th in the source sequences
at the time of the call."
Which would define an explicit descipline: one quite different from
the customary MAP but possibly more appropriate for arrays. A third
proposal might read:
"Side effects which change the number of elements are well defined
provided that only elements not yet encountered by the iteration
are changed."
This would allow adding or dropping elements from the REST of the list
but not changing the part already processed. Finally, one might have:
"Side effects which change the number of elements in a sequence
are immediately effective; the iteration proceeds by using the
the successor of element used on the previous iteration"
Which corresponds to the usual definition of MAP, but might be
inconvenient for sequences implemeted by arrays.
----
I have two conclusion points. First, that given this discovery of
a hole in the specification, we have to change the specification to
correct it, even if that is to simply mark the hole. Second, that
given the subtle ways that reasonable implementations might vary,
there should be a standard implementation that meets the spec and
that all the implementors agree to use (or at least be compatable with).
This naturally constrains implementors freedom to choose representation
and algorithm, and will sometimes extract significant performance
penalties, but is part of the price of portability. Implementors are
free to provide nonstandard extensions they consider to be better,
but only in upward compatable ways.
-------
∂21-Sep-83 1336 @MIT-MC:DLW%SCRC-TENEX@MIT-MC implied contracts in the mapping functions?
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Sep 83 13:36:43 PDT
Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Wed 21-Sep-83 16:40:39-EDT
Date: Wednesday, 21 September 1983, 16:41-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: implied contracts in the mapping functions?
To: common-lisp@SU-AI
Cc: GSB@MIT-ML
I agree: it is an error. Programs should not be depending on the
internals of mapping functions.
∂21-Sep-83 1401 KMP@MIT-MC definition/errors/...
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Sep 83 14:00:48 PDT
Date: 21 September 1983 17:02 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
Subject: definition/errors/...
To: DLW @ MIT-MC
cc: Common-Lisp @ SU-AI
I spoke with ALAN at length about this the other day. He made
a point which I think is significant -- We should not be worrying
about whether this particular feature is good/bad or and error
or undefined. We should be worrying about why. Otherwise, we'll
be doomed to simply repeat this sort of discussion ad nauseum
every time someone encounters someone with poor or questionable
programming style using any powerful operator. So while I respect
that you think it's an error, I think the only really relevant
question is "What in the language spec makes it so, and how can
we write future specs to try to avoid this sort of problem without
precluding creative and reasonable uses of powerful operators?"
∂21-Sep-83 1508 masinter.pa@PARC-MAXC.ARPA Portability and performance, standards and change
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 21 Sep 83 15:05:52 PDT
Date: 21 Sep 83 15:07 PDT
From: masinter.pa@PARC-MAXC.ARPA
Subject: Portability and performance, standards and change
To: Common-Lisp@SU-AI.ARPA
The multiple goals in language design of portability and high
performance, standard definitions and the ability to change system
definitions are often in conflict. You sometimes have to give up one to
get the other.
The primary goal of Common-Lisp (above and beyond Franz, NIL, LispM etc)
was to be COMMON. Further along the road to allowing each implementor to
decide the exact semantics of MAPC lies the current proliferation of
MacLisp dialects.
Nailing down what the mapping functions do in the presence of structure
modification on the argument list may (a) result in performance
degradations in some cases and (b) tie you to design decisions that you
will wish later that you could change, but those are in fact the real
costs of standardization and portability.
If standardization and portability are precisely the problem with
Interlisp (as Moon put it), they are also its strengths. If you have a
STANDARD, then you can't go off and change the semantics of your
implementation without in fact changing the STANDARD. Leaving it
unspecified or saying "it is an error" does not avoid the issue. It
merely increases the number of programs which will not transfer from one
"common" lisp to another (or even from one release to the next, if Moon
really meant what I thought he did) without tracking down dependence on
features which are not detectable by static or runtime analysis.
∂22-Sep-83 1225 @MIT-ML:DLW@SCRC-TENEX Re: implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 22 Sep 83 12:25:00 PDT
Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Thu 22-Sep-83 15:26:39-EDT
Date: Thursday, 22 September 1983, 15:27-EDT
From: Daniel L. Weinreb <DLW@SCRC-TENEX>
Subject: Re: implied contracts in the mapping functions?
To: HEDRICK@RUTGERS, kmp%MIT-MC@MIT-ML
Cc: Cassels%SCRC-TENEX@MIT-ML, Fahlman%CMU-CS-C@MIT-ML,
Common-Lisp%SAIL@MIT-ML
In-reply-to: The message of 19 Sep 83 16:07-EDT from Charles Hedrick <HEDRICK at RUTGERS>
Date: 19 Sep 83 16:07:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
It is dangerous to have a feature that obviously ought to be in a
language not be there, or be there in only half the implementations. No
matter what you say in the manual, people will use it where it works.
I strongly disagree. It is completely unavoidable that some people will
depend on the peculiarities of any implementation. It does not follow
that every peculiarity should be a defined part of Common Lisp that
every implementation must follow. If we are to belive what you are
saying, then EVERY place in the manual that says "it is an error" should
be changed to either say "it signals an error" or else be precisely
defined.
∂22-Sep-83 1423 @MIT-ML:BENSON@SPA-NIMBUS Re: implied contracts in the mapping functions?
Received: from MIT-ML by SU-AI with TCP/SMTP; 22 Sep 83 14:23:45 PDT
Received: from SPA-LOS-TRANCOS by SPA-Nimbus with CHAOS; Thu 22-Sep-83 14:24:41-PDT
Date: Thursday, 22 September 1983, 14:24-PDT
From: Eric Benson <BENSON at SPA-NIMBUS>
Subject: Re: implied contracts in the mapping functions?
To: Daniel L. Weinreb <DLW at SCRC-TENEX>, HEDRICK at RUTGERS,
kmp%MIT-MC at MIT-ML
Cc: Cassels%SCRC-TENEX at MIT-ML, Fahlman%CMU-CS-C at MIT-ML,
Common-Lisp%SAIL at MIT-ML
In-reply-to: The message of 22 Sep 83 12:27-PDT from Daniel L. Weinreb <DLW at SCRC-TENEX>
Date: Thursday, 22 September 1983, 15:27-EDT
From: Daniel L. Weinreb <DLW@SCRC-TENEX>
Date: 19 Sep 83 16:07:49 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
It is dangerous to have a feature that obviously ought to be in a
language not be there, or be there in only half the implementations. No
matter what you say in the manual, people will use it where it works.
I strongly disagree. It is completely unavoidable that some people will
depend on the peculiarities of any implementation. It does not follow
that every peculiarity should be a defined part of Common Lisp that
every implementation must follow. If we are to belive what you are
saying, then EVERY place in the manual that says "it is an error" should
be changed to either say "it signals an error" or else be precisely
defined.
And of course that's only the beginning. The only way to ensure that
every implementation has exactly the same behavior is to define a very
low-level virtual machine and write the entire system in terms of it.
Then there would truly be one Common Lisp, and any program which ran on
one version would run on any other. This is how UCSD Pascal is defined,
for example. Programs can be compiled on Z80's and run on 6502's. This
is not the goal of the Common Lisp language definition as I understand
it, however. I believe the intention is similar to that of Standard
Lisp, to define an @i(interchange subset). Programs which rely only on
the behavior described in the manual will run on any Common Lisp
implementation. No machine can enforce the Common Lisp standard,
although automated tools can of course aid the programmer in adhering to
it.
∂22-Sep-83 1449 HEDRICK@RUTGERS.ARPA behavior of mapping
Received: from RUTGERS by SU-AI with TCP/SMTP; 22 Sep 83 14:49:39 PDT
Date: 22 Sep 83 17:51:30 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: behavior of mapping
To: common-lisp@SU-AI.ARPA
Yes, I realize that it is possible to carry transportability to an
extreme. Obviously we cannot protect users against every possible
assumption they might make. But there are some assumptions that we know
from experience are made so universally that we ought to at least
consider that the users might be right and we might be wrong. I agree
that I can't possibly guarantee that all code will be transportable. But
it would be irresponsible to leave in something I know will cause most
users to write untransportable programs, unless there are very strong
reasons indeed. I have been involved in Lisp development and support for
a number of years. I can tell you from experience that users do in
fact depend upon the exact semantics of mapping functions. I believe
this is one of the cases where the users' expectations are so universal
that the implementors should bow to them.
-------
∂22-Sep-83 2049 ALAN@MIT-MC behavior of mapping
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Sep 83 20:49:32 PDT
Date: 22 September 1983 23:52 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: behavior of mapping
To: Common-Lisp @ SU-AI, HEDRICK @ RUTGERS
In-reply-to: Msg of 22 Sep 83 17:51:30 EDT from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
Date: 22 Sep 83 17:51:30 EDT
From: Charles Hedrick <HEDRICK at RUTGERS.ARPA>
... But there are some assumptions that we know from experience are
made so universally that we ought to at least consider that the users
might be right and we might be wrong.... it would be irresponsible
to leave in something I know will cause most users to write
untransportable programs, ... I can tell you from experience that
users do in fact depend upon the exact semantics of mapping functions....
"will cause MOST users to write untransportable programs"?
I don't think I have EVER met a user who depended this closely on the exact
semantics of any function that takes a functional argument. In fact, my
experience has been that users generally exhibit good sense about such
issues. I suggest that that good sense be reinforced by inserting a
paragraph in the manual explaining briefly that functions that take
functional arguments generally will behave unpredictable if their arguments
are diddled before they are done with them.
∂27-Sep-83 1620 JonL.pa@PARC-MAXC.ARPA THROW, and MAP
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 27 Sep 83 16:20:33 PDT
Date: Tue, 27 Sep 83 15:51 PDT
From: JonL.pa@PARC-MAXC.ARPA
Subject: THROW, and MAP
To: Common-Lisp@SU-AI.ARPA
THROW
Excelsior edition's commentary on THROW doesn't make clear whether the
evaluation of the 'result' form is to take place before or after the
tag-search.
If before, then the syntax of THROW is merely that of 'function'. If
after,
then that must be spelled out, so that side-effects in the 'result'
computation
won't occur when there is a tag-search failure.
MAP
All the recent discussion about "what happens if the mapped function
updates
the list it is mapping over" points up the non-primitive nature of the
map
series of "functions". Admittedly, the WhitePages aren't the place to
try to
distinguish a truly-primitive kernel from the common, portable subset,
but
a simple change from [Function] to [Macro] on the map entries would
forclose
a lot misguided babbling.
Given that CommonLisp has RETURN-FROM and named BLOCKs, a macro-
expansion of the mappers need not be concerned with "prog context". Is
there
any reason for continuing to push the primality of the map series over a
reasonable macro definition?
More to the point, sigh, is the lack of any reasonable iteration control
structure.
MacLisp DO just doesn't "cut the mustard". DOTIMES and DOLIST are
too-little,
too-late. LOOP in its current definition (p93) seems to preclude the
nice
MacLisp/LispM LOOP macro. Foo. Having used Interlisp's I.S.OPRS for
some
time now, I often wonder how one can get along without it. The
objection to a reasonable form of LOOP can hardly be that it is "new",
since it is essentially
a modest variant of Interlisp's I.S.OPRS which has had 10-years of
extensive use.
Nor should the objection be that old "cop out" that its syntax isn't
"Lispy"
enough [or, as the last paragraph on page 99 almost says, "... as if
it were
impossible to write programs without
Lots-of-Interminable-Silly-Parentheses"]
∂27-Sep-83 1649 @MIT-MC:Moon%SCRC-TENEX@MIT-MC THROW, and MAP
Received: from MIT-MC by SU-AI with TCP/SMTP; 27 Sep 83 16:49:07 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 27-Sep-83 19:29:12-EDT
Date: Tuesday, 27 September 1983, 19:50-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: THROW, and MAP
To: JonL.pa@PARC-MAXC
Cc: Common-Lisp@SU-AI
In-reply-to: The message of 27 Sep 83 18:51-EDT from JonL.pa at PARC-MAXC
Date: Tue, 27 Sep 83 15:51 PDT
From: JonL.pa@PARC-MAXC.ARPA
Excelsior edition's commentary on THROW doesn't make clear whether the
evaluation of the 'result' form is to take place before or after the
tag-search. If before, then the syntax of THROW is merely that of
'function'. If after, then that must be spelled out, so that side-effects
in the 'result' computation won't occur when there is a tag-search
failure.
The syntax (you mean semantics?) of THROW is not the same as of functions,
since it sees all the values resulting from evaluating its second subform.
I vote for the subforms both being evaluated before the search for a matching
tag commences, since it seems simpler for both user-understanding and
implementation ease.
LOOP in its current definition (p93) seems to preclude the nice
MacLisp/LispM LOOP macro.
In the excelsior edition LOOP was fixed to not preclude that macro.
(It used to be defined in such a way that the hairy LOOP macro was not
a consistent extension of Common Lisp's simple builtin one.)
But the hair LOOP macro is not included in the white pages.
This is partly my fault since years ago I promised to come up with
a second generation of LOOP that would fix a lot of the problems people
have complained about. In fact I did most of the design and circulated
it to a number of people, but the thing has been on the back burner for
a long time due to other responsibilities. It probably wouldn't be hard
to make the existing LOOP run in Common Lisp as a yellow pages package,
although I for one would much rather have the nicer new one. The
motivation for finishing this project (either by me or by someone else,
I don't care) will probably become a lot higher in a half year or so as
we start to see some "real live" Common Lisp implementations with actual
users.
I agree that it is quite impractical to try to do without some form of complex
iteration generator, whether it be the Interlisp one, the Maclisp one, or my
pie in the sky new one. Dick Water's LetS package should definitely be
made to run in Common Lisp as well.
∂27-Sep-83 1722 FAHLMAN@CMU-CS-C.ARPA THROW, and MAP
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 Sep 83 17:21:58 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 27 Sep 83 20:24:23-EDT
Date: Tue, 27 Sep 1983 20:24 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: THROW, and MAP
In-reply-to: Msg of 27 Sep 1983 19:50-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
I agree with Moon on both counts: THROW shold eval both its args before
searching for the tag (it is very awkward to implement it the other
way), and we all are eager to see Moon's new polished LOOP proposal
rather than rushing to implement the old one. Even we reactionaries are
about ready to accept something along these lines, but I'd like it to be
as uncluttered as possible.
-- Scott
∂27-Sep-83 1942 JONL.PA@PARC-MAXC.ARPA Re: THROW, and MAP
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 27 Sep 83 19:42:32 PDT
Date: 27 SEP 83 19:38 PDT
From: JONL.PA@PARC-MAXC.ARPA
Subject: Re: THROW, and MAP
To: Moon%SCRC-TENEX@MC.ARPA, JonL.pa@MC.ARPA
cc: Common-Lisp@SAIL.ARPA, JONL.PA@PARC-MAXC.ARPA
In response to the message sent Tue, 27 Sep 83 19:50 EDT from
Moon%SCRC-TENEX@MIT-MC.ARPA
Syntax/Semantics -- either way I had overlooked the multiple-value thing
(being confined to a system which, for the moment, doesn't have them).
Yes, I'd like to see the evaluation question settled that way -- that's
how
I've already implemented an Interlisp version -- but I'd be quite happy
to
go the other way if the majority so voted.
∂28-Sep-83 0828 Guy.Steele@CMU-CS-A Re: THROW, and MAP
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 28 Sep 83 08:28:29 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 28 Sep 83 11:18:27 EDT
Date: 28 Sep 83 1124 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: JonL.pa@PARC-MAXC
Subject: Re: THROW, and MAP
CC: common-lisp@SU-AI
In-Reply-To: "JonL.pa@PARC-MAXC.ARPA's message of 27 Sep 83 17:51-EST"
Your point about THROW is well-taken, and I will try to improve the prose.
I think that THROW was made into a special form because, although all
arguments are evaluated and thus from that point of view it could be
treated as a function, THROW has some bizarre side effects (namely
transfer of control) and most program-processing programs will probably
need to treat it as a special form anyway. (Maybe that's wrong; maybe
it just happened somewhat accidentally as we gyrated through various
versions of throws and catches.)
As for MAP, I honestly don't see what being a macro or a function has
to do with pinning down its behavior when a list being mapped over is
modified; either a macro or a function could have the surprising behavior,
and in either case the desription must be more precise.
Now, the question of whether MAP should be a function or a macro is in
itself an interesting and debatable question. It doesn't need to be
a macro for the sake of compiled code, because a compiler is free to
compile it inline unless specifically directed not to do so (with a
notinline declaration). MacLISP does this kind of inline compilation
already. As you pointed out, the RETURN-FROM technology allows
Common LISP to avoid some of the PROG-capture anomalies that occurred
in MacLISP.
I will point out that in some styles of programming it is useful to
be able to APPLY MAP (or even to MAP a MAP)!
Concerning LOOP, the Common LISP LOOP construct is compatible with the
LISP Machine LOOP construct. There is a sentence which carefully makes
the semantics of Common LISP's LOOP undefined if any form in the
construct is a symbol (it should say atom). So every valid Common
LISP LOOP must contain only non-atomic forms, and in this case the
LISP Machine LOOP has the same semantics as the Common LISP LOOP.
So any implementation is free to implement the entire LISP Machine
LOOP stuff and claim it is compatible with Common LISP; it just
won't necessarily be portable if you use the hairier features.
∂28-Sep-83 0829 Guy.Steele@CMU-CS-A THROW, again
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 28 Sep 83 08:29:11 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 28 Sep 83 11:18:46 EDT
Date: 28 Sep 83 1127 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: JonL.pa@PARC-MAXC
Subject: THROW, again
CC: common-lisp@SU-AI
In-Reply-To: "JonL.pa@PARC-MAXC.ARPA's message of 27 Sep 83 17:51-EST"
Scratch my explanations of why THROW is a special form. Moon had
the right answer (multiple values from a single argument form).
I feel silly for neglecting that point.
∂28-Sep-83 1352 GSB@MIT-ML THROW, and MAP
Received: from MIT-ML by SU-AI with TCP/SMTP; 28 Sep 83 13:52:12 PDT
Date: 28 September 1983 15:41 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: THROW, and MAP
To: Moon%SCRC-TENEX @ MIT-MC
cc: Common-Lisp @ SU-AI, JonL.pa @ PARC-MAXC
Received: from MIT-MC by SU-AI with TCP/SMTP; 27 Sep 83 16:49:07 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 27-Sep-83 19:29:12-EDT
Date: Tuesday, 27 September 1983, 19:50-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
In-reply-to: The message of 27 Sep 83 18:51-EDT from JonL.pa at PARC-MAXC
The syntax (you mean semantics?) of THROW is not the same as of functions,
since it sees all the values resulting from evaluating its second subform.
I vote for the subforms both being evaluated before the search for a matching
tag commences, since it seems simpler for both user-understanding and
implementation ease.
. . .
In my implementation of multiple values, it may be beneficial for me to
do the search first in order to find the eventual destination of the values.
I'm haven't gotten into this stuff enough to know whether i actually would
want to do it this way even if given the liberty, however.
∂28-Sep-83 2017 Guy.Steele@CMU-CS-A Burke's remarks on THROW and MAP
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 28 Sep 83 20:17:03 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 28 Sep 83 23:07:53 EDT
Date: 28 Sep 83 2321 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Glenn S. Burke <GSB@MIT-ML>
Subject: Burke's remarks on THROW and MAP
CC: common-lisp@SU-AI
In-Reply-To: "Glenn S. Burke's message of 28 Sep 83 14:41-EST"
I believe that it would be acceptable to perform THROW in the following
order:
(1) evaluate tag (2) search for catcher (3) evaluate results (4) perform unwind
However, this order would not be acceptable:
(1) evaluate tag (2) search for catcher (3) perform unwind (4) evaluate results
The point is that the results are calculated in the dynamic environment
(that includes special variables and catchers) of the THROW, bot that
of the CATCH. (Sorry, "not" that of the CATCH.)
--Guy
∂01-Oct-83 1207 RPG INIT-FILE-PATHNAME
∂29-Sep-83 2040 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA INIT-FILE-PATHNAME
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 20:39:56 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 29 Sep 83 23:41:31-EDT
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Thu 29 Sep 83 23:40:52-EDT
Date: Thu 29 Sep 83 23:40:50-EDT
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: INIT-FILE-PATHNAME
To: moon%scrc-tenex@MIT-ML.ARPA
cc: fahlman@CMU-CS-C.ARPA, dlw%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA,
bsg%scrc-tenex@MIT-ML.ARPA
I am confused in going over your messages of four weeks ago.
You say that in ZetaLISP, fs:init-file-pathname takes a file type argument
that precedes the host argument. The blue Chineual says that it takes
a program-name and a host; no mention of a file type argument. The Common
LISP Excelsior manual says the same thing. Has ZetaLISP changed incompatibly
on this function's arguments since the blue Chineual? If sop, could you
provide a few examples of the new usage for inclusion?
--Thanks,
Guy
-------
∂01-Oct-83 1207 RPG Pathnames: duh
∂29-Sep-83 2138 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA Pathnames: duh
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 21:38:01 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 30 Sep 83 00:39:39-EDT
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 00:39:02-EDT
Date: Fri 30 Sep 83 00:38:58-EDT
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: Pathnames: duh
To: fahlman@CMU-CS-C.ARPA, moon%scrc-tenex@MIT-ML.ARPA,
dlw%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA, bsg%scrc-tenex@MIT-ML.ARPA
We had been dithering about the best way to make a pathname just like
another one except for the type. Mono suggested (2 September) that
make-pathname should take an extra argument that if specified is used
to fill in all components not otherwise specified.
Duh. make-pathname already has one of those.
So what I formerly wrote as
(merge-pathnames (make-pathname :host (pathname-host x) :type "BAZ")
x)
[which, if you believe that device defaulting is controlled by the host
and not by the defaults pathname, had a bug in it and should have been
written as
(merge-pathnames (make-pathname :host (pathname-host x)
:device (pathname-device x)
:type "BAZ")
x)
] can be written simply as
(make-pathname :type "BAZ" :defaults x)
Is it not so?
--Guy
(Sigh. "Mono" => "Moon" in line 2 up there.)
-------
∂01-Oct-83 1207 RPG Duh duh duh
∂29-Sep-83 2216 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA Duh duh duh
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 22:16:20 PDT
Received: from TARTAN by CMU-CS-C with TLnet; 30 Sep 83 01:18:14-EDT
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 01:17:27-EDT
Date: Fri 30 Sep 83 01:17:24-EDT
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: Duh duh duh
To: fahlman@CMU-CS-C.ARPA, moon%scrc-tenex@MIT-ML.ARPA,
dlw%scrc-tenex@MIT-ML.ARPA, bsg%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA,
guy.steele@CMU-CS-A.ARPA
When in doubt, read the directions. It turns out that the :defaults
argument to make-pathname is explicitly documented to provide the
host component only and no others. This is as in ZetaLISP. So the
correct shortened example is probably just
(merge-pathnames (make-pathname :type "BAZ" :defaults x)
x)
which is still a bit clumsy. Maybe the right thing to do is to
provide yet another keyword arg to make-pathname; unfortunately,
"defaults" is the best name for it. What to do?
--Guy
-------
∂01-Oct-83 1208 RPG Decompressing
∂29-Sep-83 2223 STEELE@CMU-CS-C.ARPA Decompressing
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 22:23:08 PDT
Received: ID <STEELE@CMU-CS-C.ARPA>; Fri 30 Sep 83 01:26:00-EDT
Date: Fri 30 Sep 83 01:25:58-EDT
From: STEELE@CMU-CS-C.ARPA
Subject: Decompressing
To: fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, moon%scrc-tenex@MIT-ML.ARPA,
dlw%scrc-tenex@MIT-ML.ARPA, bsg%scrc-tenex@MIT-ML.ARPA,
guy.steele@CMU-CS-A.ARPA
This will sound like an idea dreamed up at 4 in the morning, but it's not
even 1:30 yet.
This is inspired by the :MONMOD feature of ITS DDT.
What is the first thing you type most of the time at a LISP?
That's right, a left parenthesis, because you invoke functions
more often than you look at variables (wild-eyed claim).
SOOO, why shouldn't a LISP implementation prompt with a left parenthesis?
This works even better if <return> acts like a close superbracket:
it's practically like typing at any random monitor's top level.
As for looking at variables, you can do as DDT does and allow the
left-paren prompt to be rubbed out, or you can just require the loser
to type "values a)" after the prompt.
--Quux
-------
∂01-Oct-83 1208 RPG Duh duh duh
∂29-Sep-83 2225 FAHLMAN@CMU-CS-C.ARPA Duh duh duh
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 22:25:08 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 01:27:44-EDT
Date: Fri, 30 Sep 1983 01:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: STEELE%TARTAN@CMU-CS-C.ARPA
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
guy.steele@CMU-CS-A.ARPA, moon%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Duh duh duh
In-reply-to: Msg of Fri 30 Sep 83 01:17:24-EDT from STEELE%TARTAN at CMU-CS-C.ARPA
I like the idea of having :DEFAULTS supply all the slots not otherwise
specified. That is a very convenient option to have in MAKE-PATHNAME.
If we must choose a different name, I suppose it could be :COPY-FROM or
something, but :DEFAULTS seems best. Would this incompatibile change
screw anyone? We don't want to make life TOO easy for the Symbolics
hackers ...
-- Scott
∂01-Oct-83 1208 RPG Decomposing
∂29-Sep-83 2243 FAHLMAN@CMU-CS-C.ARPA Decomposing
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 22:43:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 01:45:54-EDT
Date: Fri, 30 Sep 1983 01:45 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: STEELE@CMU-CS-C.ARPA
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
guy.steele@CMU-CS-A.ARPA, moon%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Decomposing
In-reply-to: Msg of Fri 30 Sep 83 01:25:58-EDT from STEELE at CMU-CS-C.ARPA
(-: The first character I type varies, but the second one is usually
rubout. If we're going to supply something for the user, why not that?
About one rubout per character typed by the user would seem to be the
proper ratio, especially for messages typed by Quuces late at night.
Better yet, let's throw the user right into the debugger -- he'll end up
there sooner or later, and letting him talk to the top-level just builds
up a false sense of security. To make it more interesting, we can offer
the user about 30 ways to proceed, all of which require him to type keys
that don't exist on any terrestrial keyboard. The only way to get out
with your files intact are to type PLUGH or to make it through the maze,
evading the pirate. :-)
-- Scott
∂01-Oct-83 1208 RPG Random idea
∂29-Sep-83 2335 FAHLMAN@CMU-CS-C.ARPA Random idea
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 23:34:54 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 02:37:36-EDT
Date: Fri, 30 Sep 1983 02:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, moon%SCRC-TENEX@MIT-MC.ARPA,
bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA
Cc: fahlman@CMU-CS-C.ARPA
Subject: Random idea
As long as we're tossing off random ideas, here's one from me. For the
second edition only, of course.
Lately I've found myself missing the LEXPRs and LSUBRs of Maclisp.
&REST has its uses, but it seems to me that returning a LIST of the rest
args is very often not what you want. Either you actualy cons up this
list, which has significant costs associated with it, or you do stack
allocation with the cdr-coding trick that Symbolics uses, which gives
you a list that evaporates if you try to pass it upward -- at best a
confusing feature and at worst downright treacherous.
What we normally want is a simple way to pass in an unbounded number of
args, a way to find out how many there are, and a way to iterate over
them. Suppose we add &MORE to the lambda-list syntax with the same
syntax as &REST -- you can only have one or the other. The variable
following the &MORE keyword is bound to the number of "more" args that
are present -- what would have been the length of the rest list. Then
just add (MORE-ARG n) as a form to access the specified more-arg. This
is SETF-able, of course. Either &MORE or &REST could easily be
implemented in terms of the other, or both could be primitive. If &MORE
is primitive, you don't have to cons and don't have those volatile
stack-lists. Implementation is trivial, I think. In fact, I now think
that it is too bad that &REST-lists got started at all.
-- Scott
∂01-Oct-83 1208 RPG Random idea
∂29-Sep-83 2335 FAHLMAN@CMU-CS-C.ARPA Random idea
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Sep 83 23:34:54 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 02:37:36-EDT
Date: Fri, 30 Sep 1983 02:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, moon%SCRC-TENEX@MIT-MC.ARPA,
bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA
Cc: fahlman@CMU-CS-C.ARPA
Subject: Random idea
As long as we're tossing off random ideas, here's one from me. For the
second edition only, of course.
Lately I've found myself missing the LEXPRs and LSUBRs of Maclisp.
&REST has its uses, but it seems to me that returning a LIST of the rest
args is very often not what you want. Either you actualy cons up this
list, which has significant costs associated with it, or you do stack
allocation with the cdr-coding trick that Symbolics uses, which gives
you a list that evaporates if you try to pass it upward -- at best a
confusing feature and at worst downright treacherous.
What we normally want is a simple way to pass in an unbounded number of
args, a way to find out how many there are, and a way to iterate over
them. Suppose we add &MORE to the lambda-list syntax with the same
syntax as &REST -- you can only have one or the other. The variable
following the &MORE keyword is bound to the number of "more" args that
are present -- what would have been the length of the rest list. Then
just add (MORE-ARG n) as a form to access the specified more-arg. This
is SETF-able, of course. Either &MORE or &REST could easily be
implemented in terms of the other, or both could be primitive. If &MORE
is primitive, you don't have to cons and don't have those volatile
stack-lists. Implementation is trivial, I think. In fact, I now think
that it is too bad that &REST-lists got started at all.
-- Scott
∂01-Oct-83 1209 RPG INIT-FILE-PATHNAME
∂30-Sep-83 1439 @MIT-MC:MOON%SCRC-TENEX@MIT-MC INIT-FILE-PATHNAME
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Sep 83 14:34:56 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 30-Sep-83 17:36:34-EDT
Date: Friday, 30 September 1983, 17:35-EDT
From: David A. Moon <MOON%SCRC-TENEX@MIT-MC>
Subject: INIT-FILE-PATHNAME
To: STEELE%TARTAN@CMU-CS-C
Cc: fahlman@CMU-CS-C, dlw%SCRC-TENEX@MIT-MC, rpg@SU-AI, bsg%SCRC-TENEX@MIT-MC
In-reply-to: The message of 29 Sep 83 23:40-EDT from STEELE%TARTAN at CMU-CS-C
Date: Thu 29 Sep 83 23:40:50-EDT
From: STEELE%TARTAN@CMU-CS-C.ARPA
I am confused in going over your messages of four weeks ago.
You say that in ZetaLISP, fs:init-file-pathname takes a file type argument
that precedes the host argument. The blue Chineual says that it takes
a program-name and a host; no mention of a file type argument. The Common
LISP Excelsior manual says the same thing. Has ZetaLISP changed incompatibly
on this function's arguments since the blue Chineual? If sop, could you
provide a few examples of the new usage for inclusion?
It was changed in Release 5, incompatibly, to take a file type argument before
the host argument. As it turns out, one almost never supplies the host argument
so the incompatibility was not serious. This change was made so that init files
could be compiled rationally; at the same time we changed the naming conventions
for init files on most hosts, to be the same as the naming conventions for
all other Lisp programs.
(fs:init-file-pathname "Zork")
=> SCRC:<MOON>ZORK-INIT
suitable to pass to LOAD and load the compiled version
if it is compiled, otherwise the source version
(fs:init-file-pathname "Zork" :lisp)
=> SCRC:<MOON>ZORK-INIT.LISP
suitable to pass to ED to edit the source of the init file
(fs:init-file-pathname "Zork" si:*default-binary-file-type*)
=> SCRC:<MOON>ZORK-INIT.BIN
suitable for a program that asks the user whether to compile
the init file after editing it
Before Release 5, the init file name would be SCRC:<MOON>ZORK.INIT for all
three of these, and if that was a compiled file one had to consult an oracle
to find the name of the source file it came from.
∂01-Oct-83 1209 RPG Random idea: bringing back lexprs
∂30-Sep-83 1447 @MIT-MC:MOON%SCRC-TENEX@MIT-MC Random idea: bringing back lexprs
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Sep 83 14:46:45 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 30-Sep-83 17:46:41-EDT
Date: Friday, 30 September 1983, 17:45-EDT
From: David A. Moon <MOON%SCRC-TENEX@MIT-MC>
Subject: Random idea: bringing back lexprs
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: steele@CMU-CS-C, rpg@SU-AI, bsg%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC
In-reply-to: The message of 30 Sep 83 02:37-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 30 Sep 1983 02:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
As long as we're tossing off random ideas, here's one from me. For the
second edition only, of course.
Lately I've found myself missing the LEXPRs and LSUBRs of Maclisp.
&REST has its uses, but it seems to me that returning a LIST of the rest
args is very often not what you want. Either you actualy cons up this
list, which has significant costs associated with it, or you do stack
allocation with the cdr-coding trick that Symbolics uses, which gives
you a list that evaporates if you try to pass it upward -- at best a
confusing feature and at worst downright treacherous.
What we normally want is a simple way to pass in an unbounded number of
args, a way to find out how many there are, and a way to iterate over
them. Suppose we add &MORE to the lambda-list syntax with the same
syntax as &REST -- you can only have one or the other. The variable
following the &MORE keyword is bound to the number of "more" args that
are present -- what would have been the length of the rest list. Then
just add (MORE-ARG n) as a form to access the specified more-arg. This
is SETF-able, of course.
Not of course. This has very strong implications for the implementation.
In particular, it requires that APPLY must copy its last argument. In our
implementation, it will pass that argument straight through to an &REST
argument if the function wants one.
Either &MORE or &REST could easily be
implemented in terms of the other, or both could be primitive. If &MORE
is primitive, you don't have to cons and don't have those volatile
stack-lists. Implementation is trivial, I think. In fact, I now think
that it is too bad that &REST-lists got started at all.
I don't see a list as particularly a bad way of representing a sequence.
It seems more natural than using numerical indices and a magic function.
What we normally want is a simple way to pass in an unbounded number of
args, a way to find out how many there are, and a way to iterate over
them.
Actually, this is debatable. Many of the functions that I have seen
use their &REST args in true list-like fashion. For instance, they use
GETF on them, or they pass them as the last argument to APPLY. It's
only sometimes that all they want to do with them is iterate over them.
I am the first to admit that the volatility of rest args is a problem,
and plan to fix it one day. In our system it would not be acceptable
for rest args that are only used "downward" to be inefficient, so it
can't just be fixed the obvious way (consing them in the heap) which is
why it hasn't been fixed yet. Some day; there is a mechanism designed
but not implemented. I don't think I would complain if Common Lisp
required a declaration that the rest arg was only going to be used
downward, and required that in the absence of the declaration they
would work like natural lists, AS LONG AS YOU DIDN'T SIDE-EFFECT them.
∂01-Oct-83 1209 RPG Pathnames: duh
∂30-Sep-83 1650 @MIT-MC:MOON%SCRC-TENEX@MIT-MC Pathnames: duh
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Sep 83 16:49:50 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 30-Sep-83 19:48:35-EDT
Date: Friday, 30 September 1983, 19:47-EDT
From: David A. Moon <MOON%SCRC-TENEX@MIT-MC>
Subject: Pathnames: duh
To: STEELE%TARTAN@CMU-CS-C, Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: dlw%SCRC-TENEX@MIT-MC, bsg%SCRC-TENEX@MIT-MC, rpg@SU-AI,
guy.steele@CMU-CS-A
In-reply-to: The message of 30 Sep 83 00:38-EDT from STEELE%TARTAN at CMU-CS-C,
The message of 30 Sep 83 01:17-EDT from STEELE%TARTAN at CMU-CS-C,
The message of 30 Sep 83 01:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Re: how to make a pathname that is like another pathname except that
certain specific components are different.
MERGE-PATHNAMES is never the right way to do this, when what you are
trying to do is to set certain components explicitly. It is the right
thing if you are a user interface.
We do this with message passing, not with MAKE-PATHNAME, so our
FS:MAKE-PATHNAME isn't much of a guide. In fact you will never see any
Lisp machine code calling FS:MAKE-PATHNAME except internally to the
pathname system itself; pathnames are always made by parsing or by
taking an existing pathname and modifying (a copy of) it with a message
such as :NEW-PATHNAME.
Since Common Lisp got rid of the Lisp machine pathname-defaults object,
the :DEFAULTS argument to our FS:MAKE-PATHNAME doesn't have much
relation to the :DEFAULTS argument to the Common Lisp MAKE-PATHNAME.
Given all this, you might as well get rid of the :DEFAULTS argument to
MAKE-PATHNAME, and instead say that the :HOST argument is required,
since all pathnames must have a host, and if you don't have anything
specific to use for a host you use (PATHNAME-HOST DEFAULT-PATHNAME).
An alternative philosophy would say that the :HOST argument is optional,
but if you don't specify it you have no right to complain about the
"random" host that the function happens to choose. The main problem with
this is that programs written on non-networking Common Lisp implementations,
where you don't have to think about hosts, would likely be non-portable.
Then if you want MAKE-PATHNAME to also fulfill the function of the
:NEW-PATHNAME message, you could give it an argument that is a pathname
from which to take nonspecified component values. :DEFAULT would be a
better name than :DEFAULTS for this. I think it would be a little more
tasteful to use a separate function for this operation, but others
might reasonably disagree.
This letter replaces my previous comment (of a month or two ago) in
which I suggested adding a new keyword to MAKE-PATHNAME, to be a
pathname to be selectively modified, the misguided goal then being to
avoid flushing the :DEFAULTS argument.
If I may digress back to the very original topic of this discussion,
which was Scott asking how he was supposed to write COMPILE-FILE in the
absence of a way to side-effect pathnames, the answer is as follows.
You can't just bash the input file name's type unconditionally, since
COMPILE-FILE takes an optional output-file argument.
(defun compile-file (input-file &key (output-file "") ...)
(setq input-file (merge-pathnames input-file
(alter-pathname *load-pathname-defaults*
:type "LISP")))
(setq output-file (merge-pathnames output-file
(alter-pathname input-file
:type "BIN")))
...)
where "LISP" and "BIN" are really implementation-dependent and
alter-pathname is whatever emerges from the current discussion.
Incidentally, merge-pathname-defaults is an attempt to avoid the need
for that call to alter-pathname all the time. As defined in the Lisp
machine currently, it doesn't actually work for that. If a function
to do "merge-pathnames with the type component of the default altered"
is put into Common Lisp I suggest that merge-pathname-defaults is not
a very good name for it. Call this a withdrawal of any previous
suggestion I may or may not have made that merge-pathname-defaults
should be included under that name.
∂01-Oct-83 1209 RPG Pathnames: duh
∂30-Sep-83 2216 FAHLMAN@CMU-CS-C.ARPA Pathnames: duh
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 Sep 83 22:16:27 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 21:56:44-EDT
Date: Fri, 30 Sep 1983 21:56 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <MOON%SCRC-TENEX@MIT-MC.ARPA>
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
guy.steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA, STEELE%TARTAN@CMU-CS-C.ARPA
Subject: Pathnames: duh
In-reply-to: Msg of 30 Sep 1983 19:47-EDT from David A. Moon <MOON%SCRC-TENEX at MIT-MC>
If I understand Moon's message correctly, he would be happy with a
MAKE-PATHNAMES function that takes no default (or defaults) argument,
but just the names of various fields to be filled in: :HOST, :TYPE,
:VERSION, etc. :HOST is mandatory. In addition to this, there would be
a function named ALTER-PATHNAME that takes an original pathname and any
number of field arguments. A copy is made of the original, but with the
specified fields over-riding those in the original.
MERGE-PATHNAME-DEFAULTS would be flushed. I personally would find it
much less confusing to completely separate the idea of merging from the
idea of altering, and not try to roll them into a single function. It's
a little verbose that way, but how many times a day do you write
filename code anyway?
All of that looks good to me. If people would rather go with a :DEFAULT
argument to MAKE-PATHNAME (which if supplied would make it do what
ALTER-PATHANMES does in the description above) I would go along with
that, but I agree with Moon that it is clearer to have separate
functions for these two distinct uses. Does anyone object to
ALTER-PATHNAME as a separate function? (That name makes it sound like a
destructive modification, but I can't think of anything better.)
On a related matter, is there any good reason we cannot allow null HOST
slots in pathanmes, but require each implementation to somehow provide a
default host if none is supplied? On most time-sharing systems, this
simply be "this machine". On personal machine networks, it might
mean "the central file server". On truly distributed file systems, in
which neither "this machine" nor "the central file server" is right, it
would be handled in some locally tasteful way -- maybe ask the user or
have him give a default in his init file. That all seems more intuitive
to me than requiring a pathname always to have a host because the host
governs its behavior.
-- Scott
∂01-Oct-83 1210 RPG Random idea: bringing back lexprs
∂30-Sep-83 2224 FAHLMAN@CMU-CS-C.ARPA Random idea: bringing back lexprs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 Sep 83 22:22:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Sep 83 22:37:40-EDT
Date: Fri, 30 Sep 1983 22:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <MOON%SCRC-TENEX@MIT-MC.ARPA>
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
steele@CMU-CS-C.ARPA
Subject: Random idea: bringing back lexprs
In-reply-to: Msg of 30 Sep 1983 17:45-EDT from David A. Moon <MOON%SCRC-TENEX at MIT-MC>
The SETF-ability of &MORE args is certainly flushable if it causes real
trouble. SETF would seldom be useful here. Your other objections to
&MORE seem kind of weak.
You say that a list is a more natural way to represent a sequence than
an index and accessor. I agree. But the index scheme is more tasteful
than either a pseudo-list or a list that is consed up when it doesn't
have to be. Your system goes to great lengths and tolerates
considerable grunginess to avoid this bit of consing, so you must agree
on the latter point.
You say that many of the functions you've seen really want to use their
&rest args in true list-like fashion. That's a good argument for
keeping &rest, but not a good argument for using it exclusively. I
haven't gone back and counted, but I think that if &MORE were around,
our system code would use it 80% of the time and &REST only about 20%.
There are an awful lot of things like + around that just want to iterate
over their arguments.
Finally, you say that one of these years you will fix up your system to
make the pseudo-lists behave like real lists. This is a good move, but
sounds like a lot of work for no reason. Wouldn't it be nice to skip
all this new hair, along with the hairy cdr-coding on the stack, and
just cons up a righteous list when the user asks for one and give him an
alternative if he doesn't want to cons? And besides, while this is a
possible solution for you, it doesn't do much for other implementations
that don't cdr-code. They are stuck with consing a list every time. (I
don't want to argue about whether cdr-coding is a good thing -- we want
this langauge to be easily portable, and cdr coding is tough on some
machines.)
I had hoped that everyone else would jump in to tell you that you are
just being stubborn... oops, that ploy has been used.
-- Scott
∂01-Oct-83 1210 RPG Pathnames: duh
∂30-Sep-83 2242 @MIT-MC:MOON%SCRC-TENEX@MIT-MC Pathnames: duh
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Sep 83 22:41:52 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 1-Oct-83 01:43:37-EDT
Date: Saturday, 1 October 1983, 01:42-EDT
From: David A. Moon <MOON%SCRC-TENEX@MIT-MC>
Subject: Pathnames: duh
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: bsg%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC, guy.steele@CMU-CS-A,
rpg@SU-AI, STEELE%TARTAN@CMU-CS-C, Moon%SCRC-TENEX@MIT-MC
In-reply-to: The message of 30 Sep 83 21:56-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 30 Sep 1983 21:56 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
If I understand Moon's message correctly....
You do. All the alternatives in your first three paragraphs are okay with me.
On a related matter, is there any good reason we cannot allow null HOST
slots in pathanmes, but require each implementation to somehow provide a
default host if none is supplied?
I'm not sure what this really means. Do you expect PATHNAME-HOST to be able
to return NIL, or does this simply mean that if no :HOST is specified to
MAKE-PATHNAME, it chooses a default host in some way that is appropriate
to the implementation? A related question is do you expect (PARSE-PATHNAME "")
to return something that is less specific about what host it is for
than what (PARSE-PATHNAME "<FAHLMAN.HACKS>FOO.LSP.105") returns? How
about (PARSE-PATHNAME "RUMPLESTILTSKIN"), about the most complex string
that doesn't need a host because it doesn't contain any delimiters? [Wait
a minute: what about hosts that store pathnames in lower case, allow a maximum
of six characters in a file name, or use the letter "L" as a delimiter
between name and type fields?]
Do you mean to refer to PARSE-PATHNAME (the fundamental building block
of pathname user interfaces) or to MAKE-PATHNAME (the fundamental
primitive for programs that make pathnames) or to both?
On most time-sharing systems, this
simply be "this machine". On personal machine networks, it might
mean "the central file server".
There are about ten central file servers that I use more than once a
week. There are approximately 800 (last time I counted) file servers that
I could use if I so chose; probably I have used 30 or 40 of them in my
life. So I don't think your "personal machine networks" case applies to
any personal machine networks I know about.
On truly distributed file systems, in
which neither "this machine" nor "the central file server" is right, it
would be handled in some locally tasteful way -- maybe ask the user or
have him give a default in his init file.
I guess this is what we do.
In the Lisp machine's own pathname system, when parsing a pathname or
making a pathname (either of them) with no other specification of a host,
(send (fs:default-pathname fs:*default-pathname-defaults*) :host) is used,
which is the user's declared home host, or a host explicitly specified
at login time. There is no particular reason to believe that all of a
user's files are on that host, but it is a less random default than any
other. (fs:default-pathname fs:*default-pathname-defaults*) is set to
FOO.LISP on the user's home directory at login time, and not normally
changed. This appears to be the same thing as *DEFAULT-PATHNAME-DEFAULTS*
in Common Lisp (excelsior).
That all seems more intuitive
to me than requiring a pathname always to have a host because the host
governs its behavior.
I don't understand what the proposed difference from requiring a pathname
always to have a host is. Possibly the answer is that the pathname specification
already does what you want, actually?
∂01-Oct-83 1210 RPG Random idea: bringing back lexprs
∂30-Sep-83 2251 @MIT-XX:MOON@SCRC-TENEX Random idea: bringing back lexprs
Received: from MIT-XX by SU-AI with TCP/SMTP; 30 Sep 83 22:51:02 PDT
Received: from SCRC-EUPHRATES by SCRC-SPANIEL with CHAOS; Sat 1-Oct-83 01:51:39-EDT
Date: Saturday, 1 October 1983, 01:51-EDT
From: David A. Moon <MOON at SCRC>
Subject: Random idea: bringing back lexprs
To: Scott E. Fahlman <Fahlman at CMU-CS-C>
Cc: bsg at SCRC, dlw at SCRC, rpg at SU-AI, steele at CMU-CS-C
In-reply-to: The message of 30 Sep 83 22:37-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri, 30 Sep 1983 22:37 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
The SETF-ability of &MORE args is certainly flushable if it causes real
trouble. SETF would seldom be useful here. Your other objections to
&MORE seem kind of weak.
You say that a list is a more natural way to represent a sequence than
an index and accessor. I agree. But the index scheme is more tasteful
than either a pseudo-list or a list that is consed up when it doesn't
have to be. Your system goes to great lengths and tolerates
considerable grunginess to avoid this bit of consing, so you must agree
on the latter point.
It's not so clear the index scheme is more tasteful than a pseudo-list.
Only a tiny fraction of the functions that take &REST arguments need to
worry about the dynamic extent of the list. The main problem comes in
explaining it to new users, who always barf (quite legitimately).
You say that many of the functions you've seen really want to use their
&rest args in true list-like fashion. That's a good argument for
keeping &rest, but not a good argument for using it exclusively. I
haven't gone back and counted, but I think that if &MORE were around,
our system code would use it 80% of the time and &REST only about 20%.
There are an awful lot of things like + around that just want to iterate
over their arguments.
Having both is probably the right thing (even though it would slow down
our interpreter slightly; but it's already cretinously slow, so who cares).
Let's let one more flower bloom.
Finally, you say that one of these years you will fix up your system to
make the pseudo-lists behave like real lists. This is a good move, but
sounds like a lot of work for no reason. Wouldn't it be nice to skip
all this new hair, along with the hairy cdr-coding on the stack,
The cdr-coding on the stack isn't hairy at all.
and
just cons up a righteous list when the user asks for one and give him an
alternative if he doesn't want to cons?
Your proposed alternative is no alternative for the functions that want to
see a list and don't want to cons, which I maintain is the majority.
And besides, while this is a
possible solution for you, it doesn't do much for other implementations
that don't cdr-code. They are stuck with consing a list every time.
I see no reason why a non-cdr-coded Lisp would be unable to allocate a
list in a stack. It simply requires that the list take up twice as much
storage, a price they are already willing to pay when allocating in the
heap, where the extra storage use costs you much more than it does in
the stack.
∂01-Oct-83 1206 RPG Pathnames: duh
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 Sep 83 23:22:09 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 1 Oct 83 02:25:22-EDT
Date: Sat, 1 Oct 1983 02:25 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <MOON%SCRC-TENEX@MIT-MC.ARPA>
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
guy.steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA, STEELE%TARTAN@CMU-CS-C.ARPA
Subject: Pathnames: duh
In-reply-to: Msg of 1 Oct 1983 01:42-EDT from David A. Moon <MOON%SCRC-TENEX at MIT-MC>
Yes, I was proposing that PATHNAME-HOST be allowed to return NIL. For
certain low-level things this might make some sense, especially in an
environment where you are accessing the same host 95% of the time.
(Moon's routine use of many hosts is unusual right now, though it will
probably be the norm pretty soon.) My problem was that I lost sight of
the fact that essentially all interesting pathnames come from
PARSE-PATHNAME and not from an explicit call to MAKE-PATHNAME or
something like that. And, as Moon has pointed out, PARSE-PATHNAME has
to make assumptions about the host, even in the simplest cases. So
(parse-pathname "<fahlman>foo.lisp") has to guess what host to use at
the time the pathname is created, and it may as well record that guess
in the resulting pathname rather than pretending to be uncommitted as to
host. Actually, only the type of host has to be guessed, but we've been
around that issue before, and separating the concepts of host and
protocol seems to buy us nothing useful.
Anyway, I now see why a null host is not a useful concept. Thanks for
bringing this into better focus.
-- Scott
∂01-Oct-83 1500 RPG My comments on the Excelsior manual
∂30-Aug-83 1559 @MIT-MC:Moon%SCRC-TENEX%MIT-MC@SU-DSN My comments on the Excelsior manual
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Aug 83 15:40:15 PDT
Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; Tue 30-Aug-83 18:37:20-EDT
Date: Tuesday, 30 August 1983, 18:31-EDT
From: David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>
Subject: My comments on the Excelsior manual
To: Fahlman%CMU-CS-C@SU-DSN, Steele%CMU-CS-C@SU-DSN, RPG@SU-AI,
Moon%SCRC-TENEX%MIT-MC@SU-DSN, DLW%SCRC-TENEX%MIT-MC@SU-DSN,
BSG%SCRC-TENEX%MIT-MC@SU-DSN
File-References: SCRC:<MOON>COMMON-LISP.EXCELSIOR
Substantive technical comments on Excelsior edition of Common Lisp manual.
There are also a lot of typographical and clarity-of-explanation
comments; I will send a marked-up hardcopy by US mail.
p. 25: integer and ratio are not an exhaustive partition of rational?
fixnum and bignum are not an exhaustive partition of integer? Yow!
Such possibilities for language extension...
p. 26 (second to last paragraph): it says that an implementation may not
unilaterally add new subtypes to common. But since common includes all
types created by defstruct, anyone using defstruct is adding new subtypes
to common. I think this is just a wording problem, probably this has
to do with the word "exhaustive union" and you're trying to say that only
the Common Lisp committee can add new subtypes to common that are not
subtypes of the existing list of subtypes. But I'm not sure, which is
why this is included here.
p. 40: there is a typo in which the arguments to COERCE are given in the
wrong order, probably because you were reasoning by analogy from concatenate,
which appears in the same sentence. Since THE, MAP, and MERGE also put the
type first, I suggest that COERCE is broken and should be changed to put the
type first. However, this was rejected the last time I suggested it. Since
the manual is inconsistent, I suggest that it is only a clarication to change
the order of arguments now.
p. 43 (third paragraph, parenthesized sentence): Does this mean that no
extensions to the evaluator are allowed, or that they have to use data
types that are not a subtype of common? This depends on what "Common Lisp
data object" means exactly.
p. 48 (first sentence): &key keywords should not be required to be in the
keyword package, only encouraged to be. There are occasional reasons to
have private-packaged keyword-argument names. This applies to the second
paragraph on p.49 also.
p. 63 (third paragraph): This is the first of several typos that think
that EQUAL compares all arrays element by element (it used to, but now it
only compares strings and bit vectors). I suggest the introduction of
a new function EQUALC ("equal components") that compares numbers and
characters the way EQUAL does, but compares arrays the way EQUALP does
(of course, when comparing strings the individual characters are compared
the way EQUAL does, case-dependently). Another typo is on p.195 (copy-seq).
p. 69: It would be difficult for us to enforce the restriction that funcalling
the result of SYMBOL-FUNCTION of a special form (not a macro) WILL signal
an error. I suggest that it IS an error.
p. 87: Declarations are not allowed at the beginning of the body of a COMPILER-LET,
I think. Certainly declarations of the variables being bound -at compile time-
would not be meaningful. It is probably best to require use of LOCALLY to
put declarations here. COMPILER-LET is not in the table on p.117.
p. 103: In setting MULTIPLE-VALUES-LIMIT, what should I do about the fact
that on the LM-2 MULTIPLE-VALUE-PROG1 has a different limit on the number
of values than does everything else. Should I set MULTIPLE-VALUES-LIMIT
to the higher limit, and say that MULTIPLE-VALUE-PROG1 has a bug (hopefully
it signals an error if you exceed its limit), should I set MULTIPLE-VALUES-LIMIT
to the lower of the two limits, or should I make MULTIPLE-VALUE-PROG1 accept
more values (and hence be slower and more prone to stack-frame-overflow
errors). None of this applies to the 3600; no problems with multiple values
there.
p. 112: Is it a requirement that redefining a special form globally with
a macro must work? Or is this just an example? I don't think it works
now in our implementation.
p. 130: Is GENSYM required to return G7 rather than G0007, or is that
just an example? In either case there should be a rationale or
compatibility note. But there is also the technical issue of which it is.
p. 130: keywordp should be nil for all non-symbols, not an error. I.e.
keywordp should be a data type predicate, not a symbol operation.
p. 141: the new-nicknames argument to rename-package should be &rest,
not &optional, for uniformity.
p. 168: shouldn't the third value of decode-float and integer-decode-float,
the sign, be an integer (1 or -1) rather than a float? Same for float-sign
when given only one argument. Maybe there's a reason for making this be
a float, that I don't see and that isn't set forth in the manual.
p. 175: I feel that BYTE-SPECIFIER ought to be a data type for declaration
purposes (but an implementation is allowed not to support it as a data type
for discrimination purposes). Say that BYTE-SPECIFIER may or may not be
a subtype of NUMBER, depending on the implementation.
p. 189: I don't like MAKE-CHAR, since its arguments are not consistent
with the other MAKE-xxx functions, and the function seems quite redundant
with CODE-CHAR. I suggest making CODE-CHAR accept characters as well
as integers as its first argument, or else making CHAR-BITS and CHAR-FONT
SETF'able.
p. 191: In an implementation that doesn't have "super bits", is
(char-bit char :super) always false or is it an error? This may just be
a matter of clarity of explanation.
p. 199 (replace): What happens if sequence1 and sequence2 are not the same
object, but share storage because they are lists with shared substructure
or because one of them is a displaced array? I propose that the result
be undefined, since it is expensive to check for and not a very useful
case to support.
p. 213: PUSHNEW takes the same keyword arguments as ADJOIN (probably this
is only a typographical error that no keyword arguments are listed).
p. 216 (SUBLIS): are the cars of the alist elements required to be symbols,
as in Maclisp and implied by the first sentence of SUBLIS's description,
or are any objects acceptable (i.e. SUBLIS just acts as if it calls ASSOC
its first argument and its keywords)? I prefer the latter.
p. 229: What happens when array B is displaced to array A and their element
types are not the same? Okay for this to be an error, but not okay to signal
an error (we want it as a language extension).
p. 230: What happens when array-total-size-limit is a function of the element
type? Should this constant be set to the minimum over all element types?
p. 233: Is this feature that a third argument of t to the bit functions means
to use the first argument as the third argument really a win? Maybe one should
simply pass the first argument twice in this case. I don't feel very strongly
about this, but it seems like a kludge.
p. 241 (STRING): It doesn't mention using STRING to coerce a character to
a 1-element string. My vague memory is that this was an accepted change to
the language (at the time character objects were made mandatory and the
ability for an implementation to use integers instead of characters was
removed).
p. 248: The "named structure" stuff in defstruct is confused. The term
"named" is being used to mean two different things. There are two kinds
of defstructs: One is a subtype of STRUCTURE; TYPEP and TYPE-OF know how
to find the type name symbol for any object that is a structure. In some
implementations a structure is a vector with its type name in element 0,
and a magic "I am a structure" bit set. In other implementations, STRUCTURE
is not a subtype of any other COMMON type (e.g. in NIL STRUCTURE is
a subtype of EXTEND). When making this type of defstruct, the user does
not and cannot know exactly what type defstruct will make, since it is
implementation-dependent. The other kind of defstruct is one where the user
has requested a specific data type, such as VECTOR or LIST. In this case
TYPEP and TYPE-OF cannot be guaranteed to work (and in all implementations
I know of they won't work). In this second kind of defstruct, "named" just
means that defstruct automatically allocates a structure slot containing
the name symbol.
I suggest that (:type structure) mean the same as not specifying :type,
namely an object for which TYPE-OF and TYPEP "work". :unnamed is illegal
in connection with this, and :named is redundant. I suggest then that
structure be made a legal type specifier again, for consistency with this.
It means only "defstructs of the first kind."
For the non-structure :types, :unnamed is redundant.
Hence I suggest that :unnamed be flushed.
p. 249: "Moreover, astronaut will have its own access functions for
components defined by the person structure." Did we really agree to
this? I don't recall ever hearing of this before. It is incompatible
with previous usage, and seems useless to me.
p. 250: I suspect that the :eval-when option to defstruct is unnecessary
and should be removed. I think it was put in to get around a bug in the
Lisp machine compiler that was fixed years ago. I could be misremembering.
p. 254: I suspect that *EVAL is called only by "FEXPRs" and should be deleted
from the white pages. It exists internally in the evaluator, of course.
p. 257 (second and fourth paragraphs, and parentheses in the first paragraph):
We agreed to change the rules for * to be consistent with what was printed,
rather than aligned with +, but the manual wasn't updated.
p. 263: are INPUT-STREAM-P and OUTPUT-STREAM-P type predicates like streamp,
or is it an error to call them on objects that aren't streams? This may
just be a textual clarity issue. INPUT-STREAM and OUTPUT-STREAM are not
in Table 4-1.
p. 264 (last sentence): The file is only deleted if it was newly-created.
Not if appending or overwriting an existing file.
p. 279: When #+/#- skips a form, certain read errors should be suppressed.
This is necessary in order to use #+ to conditionalize code that runs in
multiple implementations, or multiple environments with different packages
present. The things to be suppressed include forms after #. and #, ,
floating-point exponent range errors, qualified name errors (no such package,
no such external symbol), #n=. (#+lispm #1= <a> #+spice #1= <b> <c> #1#)
should work and not complain that the "tag" 1 is used twice, except if
the "lispm" and "spice" features are both true.
p. 281: What does the from-readtable argument to COPY-READTABLE default to?
The manual directly contradicts itself. I suggest that it default to the
value of *READTABLE*, but that NIL mean "the standard Common Lisp readtable,
i.e. the value of *READTABLE* before any side-effects on the variable or
on the readtable were perpetrated."
p. 284 (last paragraph): When the printer decides whether a symbol's name
must be slashified because it looks like a number, is this decision dependent
on the value of *READ-BASE* or the value of *BASE*. In other words, what
controls whether the symbol FF prints as FF or \FF? I suggest *BASE*.
p. 287: What's the initial value of *PRINT-PRETTY* ? I suggest NIL.
pp. 290, 296: "Ascii streams" should be called "Character streams", since
the character code in use is not necessarily Ascii.
pp. 290, 296: I'd still like to flush the feature that T and NIL as output
streams have special meanings. This is a holdover from Maclisp. The main
problem with this feature is that FORMAT uses T and NIL to mean something
incompatible with this.
p. 290: Recursive reads need control over eof handling. Having the eof-errorp
of the top-level call to read controls what happens isn't good enough. For
example, the semicolon reader macro has to read until a Return character or
EOF; it should not be an error for a comment to end at end-of-file without
a carriage return (it is all too easy for a user to forget to put in the
carriage return). I suggest that in recursive reads, eof-errorp = nil means
return eof-value from the inner call to read regardless of the top-level read's
arguments, and eof-errorp = t means look at the top-level read's arguments,
and either signal an error or throw back to the top-level read and return
its eof-value, but in neither case return from the inner read. Then fix
all examples that say (READ stream NIL NIL T) to be (READ stream T NIL T).
p. 292: READ-DELIMITED-LIST should allow comments as well as whitespace
between the last object and the delimiter.
p. 293 (READ-LINE): What happens if end-of-file terminates an empty line
(the second to last sentence says that when end-of-file terminates
a non-empty line, the line and T are returned)? Should "" and T be
returned, or should the function take eof-errorp and eof-value arguments?
Zetalisp's READLINE function does the latter.
p. 294 (READ-FROM-STRING): Maybe the two optional arguments should be
keywords, to make things more uniform. I suggest that :EOF-ERROR
should default to true unless :EOF-VALUE is specified and :EOF-ERROR
is not specified. This makes one wonder whether there should be two
keywords or one.
p. 297 (WRITE-CHAR): Do we really want this to return NIL? All the
other writers return what they wrote (actually, their first argument,
which is not necessarily exactly what they wrote).
p. 298 (first paragraph): Regardless of what characters TERPRI on a
stream outputs to the physical device, it must be required that
(WRITE-CHAR #\RETURN stream) writes exactly the same characters. Or
is this not true, in which case you better say so very explicitly.
p. 298 (last line): I assume it's a typo that WRITE-BINARY-OBJECT
can only write arrays of integers, not arrays of all numbers, since
it can write all kinds of numbers as scalars.
p. 299: ~F appears to require negative prefix parameters, which previous
format operators didn't require. Say in the fourth paragraph on page 299
that minus signs may be used in prefix parameters.
p. 303: I think that if the third prefix parameter to ~E is omitted,
the exponent should use as many digit positions as required, rather than
using exactly 2. This would make e be treated the same as w and d.
p. 305: I suggest the following exception handling in ~$:
If the arg is too small, it is taken to be zero.
If the arg is too large, it is printed with an exponent. If w is not
specified, too large means something like 40 or 64 or 100 digits; this
could be left to the implementation.
If the arg is rational, it is first coerced to a single-float (see below).
If the arg is not a number, or complex, it is printed in ~wD format.
pp. 302-305: I suggest that when a rational is printed in ~F, ~E, ~G,
or ~$ format, an implementation be permitted either to coerce it to
single-float or to do something that retains more precision and doesn't
risk exponent overflow, at its discretion. "Something" could be
coerce to long-float or could be format it "exactly", except that if
the number of digits is not specified and a ratio that does not have
an exact decimal representation (e.g. 1/3) is specified, a finite
number of digits must be printed.
p. 306: ~G should be replaced by ~@*.
p. 307: The example of ~? is not consistent with the text. Possibly this
is a typo and the format string should have started ``"~1{~?~}~%~V...'',
but I'm not sure. If so, be sure to point out that the ~? is expanded
outside of the iteration caused by the braces, and before the braces
pick up their argument (the list to iterate over). This is the same
as use of ~V inside of braces.
p. 311: Does ~↑ with three prefix parameters do inclusive (<=) or
exclusive (<) comparison? Ugh, bletch!
p. 312: I think we agreed to change the arguments to Y-OR-N-P and
YES-OR-NO-P to be ``&optional format-string &rest format-args''. This
is compatible in the usual case where one argument is supplied and it
doesn't contain any tildes, and is much more useful than specifying a
stream; one never wants to change the stream locally, rather than
globally by binding *QUERY-IO*.
p. 317: Some file systems lack devices, types, or versions, hence you
need a value for these components in pathnames for those file systems.
The Lisp machine uses the keyword :UNSPECIFIC for this. This is different
from NIL, which means that the component was not specified by the pathname
and can be supplied by merging. Most file systems either never allow
a given component to be :UNSPECIFIC, or require it always to be :UNSPECIFIC,
but there are some where this is not the case. ITS, for example, can
have either a type or a version, but not both. When it has a version, the
type is :UNSPECIFIC. When it has a type, the version is :UNSPECIFIC.
When it has neither, both components are NIL. It may be possible to
get rid of :UNSPECIFIC and use NIL both to mean "this component was
not specified" and to mean "this component cannot be specified", but
this would require more complexity in the merging process.
p. 318: TRUENAME of a stream should be the truename of the file actually
open. This cannot be done by first converting the stream to a pathname
then taking the truename of that. File system operations performed after
the stream was opened might have changed the mapping of the stream's pathname
into a truename, for instance if the version of the stream's pathname
is :NEWEST and a newer file was created.
p. 319: If TRUENAME returns NIL if there is no such file, it is identical
to PROBE-FILE. If it quietly returns its argument, it is a liar. Probably
best to error. Then PROBE-FILE is TRUENAME except that it returns NIL for
a file-not-found error (but not for other errors such as directory-not-found,
file name illegal, or foreign host not responding).
p. 319: Flush the stuff about "conventions" in parse-namestring. parse-namestring
should take a junk-allowed argument that defaults to nil, like parse-integer.
Shouldn't start and end be keywords, like for most other functions that take
such arguments? By analogy with parse-integer, all of the arguments to
parse-namestring except the first should be keywords.
p. 320 (pathname-plist): I don't think it is wise to put property lists on
pathnames in Common Lisp. Especially when you don't say anything about
whether or not pathnames are "interned", i.e. does parse-namestring called
twice with the same arguments return two pathnames that share the same property
list, or two distinct pathnames, or is this implementation-dependent. Better
not to include any operations that perform side-effects on pathnames in Common
Lisp, so that only EQ can tell whether they are "interned." This means you
have to define what EQUAL means for pathnames. I see that page 63 says that
EQUAL compares pathnames by components, which is good, but this should be
mentioned in the pathname chapter also. EQL on pathnames should be the same
as EQ, and hence not useful, and this should be mentioned in the pathnames
chapter.
p. 321: INIT-FILE-PATHNAME should take an optional argument that is the file
type. Whether this argument affects the result depends on the host (not
on the Common Lisp implementation!). To be consistent with FS:INIT-FILE-PATHNAME
in Zetalisp, the type argument should come before the host argument.
p. 322 (second paragraph): Since all pathnames include a host, merging cannot
be responsible for putting in the default device. Pathname parsing must
do this; parsing a string that specifies a host puts in a device component,
which is the default file device unless the string specifies an explicit
device. Also the description of merging, and much of the rest of the pathname
chapter, doesn't know that MERGE-PATHNAME-DEFAULTS was flushed (over my mild
protests that both MERGE-PATHNAMES and MERGE-PATHNAME-DEFAULTS are useful).
pp. 322-324: Logical pathnames are useless without a standardized syntax. The
logical pathname system here is based on an obsolete specification of logical
pathnames in the Lisp machine, hence is not attractive to us. I suggest that
logical pathnames not be included in Common Lisp this time around; they can
be standardized later when they are better understood.
p. 325 (:element-type standard-char): What happens if the input file in fact
contains a non-character? Is this a case of "is an error" or "signals an
error"? What happens if the user calls WRITE-CHAR with a non-standard character?
What about READ? Are any strings whose printed representation is read from a
stream with :element-type standard-char guaranteed to contain only standard chars?
If READ-CHAR and WRITE-CHAR are required to check and signal an error, does this
requirement extend to :element-type string-char as well? How about READ-BYTE
and WRITE-BYTE checking that the bytes fit in the byte size declared by the
element-type? The best thing for right now is probably to leave the specification
loose and let implementations decide how much error checking they want to have.
p. 326: :if-exists :rename and :if-exists :rename-and-delete, like :if-exists
:supersede, should be encouraged not to affect the existing file until the
stream is closed, and not to affect it at all if the stream is closed in
abort mode. Should this be required rather than encouraged? Encouraged is
probably better since file systems vary so widely in their capabilities.
Explain what :if-exists :supersede means more precisely. Is it permissible
for this to mean the same as :rename, or :rename-and-delete? Note that
:supersede rather than :error is the default when the file system does not
have versions, since the pathname component can't be :newest in this case.
p. 327: clarify that in :if-does-not-exist :create mode, "proceed as if
it had already existed" does not include any processing directed by the
:if-exists argument. Someone here was confused by this.
p. 328 (rename-file): I think we agreed that values saying what was done,
rather than t, should be returned. The Zetalisp RENAMEF function returns
three values, which are the second argument (new-name) after merging with
the first argument so that renaming leaves unspecified components unchanged,
the truename before renaming, and the truename after renaming.
p. 328 (rename-file and delete-file): if it is an error to specify a pathname
containing a :wild component, what about nil components? Do they default
by merging with some default defaults, or are they an error?
p. 328 (file-creation-date): People here find the word "creation-date"
(used by Zetalisp) very ambiguous and confusing. I suggest that this
function be named file-write-date or file-written-date (depending on our
grammatical preferences).
p. 328 (file-position): This can't work easily when there is character
set translation (including translation of the Return character to a
VAX/VMS or OS/360 record boundary). Should file-position be defined to
return NIL when the element-type of the stream is one that requires such
translation, or should it be required to return the equivalent number
of READ-CHAR/WRITE-CHAR operations, or should it be required to return
a number in the units in which the file is actually read or written?
This is a probably for file-length, too.
file-position with two arguments should use :start and :end rather
than nil and t (or do I mean rather than t and nil? That's the point.)
Bi-directional streams should have separate read and write positions,
shouldn't they?
p. 329: I don't approve of making the filename argument to LOAD
optional. Am I overruled by a concensus of the committee? I don't
recall this ever being discussed.
p. 335: The string subform of CHECK-TYPE is evaluated.
p. 335: The syntax for ASSERT hasn't been updated to the new syntax
we agreed on, which flushes the kludgey use of string as a delimiter.
string is evaluated now.
p. 347: Shouldn't the symbols on *FEATURES* be keywords? If even
implementation-specific elements of *FEATURES* go in the LISP package,
they can cause accidental sharing. In general implementations have
to be careful about adding their own symbols to the LISP package,
since this could make some programs become unportable (until they
do a SHADOW).
Note that one does not write a colon in the #+ (or #-) syntax; all
symbols in that syntax are assumed to be keywords.
∂01-Oct-83 1501 RPG Moon's comments on Excelsior
∂30-Aug-83 2154 FAHLMAN@CMU-CS-C.ARPA Moon's comments on Excelsior
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 Aug 83 21:54:00 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 31 Aug 83 00:55:06-EDT
Date: Wed, 31 Aug 1983 00:55 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA
Cc: moon%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
bsg%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA, fahlman@CMU-CS-C.ARPA
Subject: Moon's comments on Excelsior
In-reply-to: Msg of 30 Aug 1983 18:31-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
Guy,
A number of the issues raised by Moon need to be ruled on explicitly,
one way or the other, since they make a difference in actual code that
is very close to being wrapped up. I don't think that many of Moon's
points are controversial, in the sense that anyone will care a lot about
which way things go, but having SOME decision is critical. What may be
controversial is the question of whether we are willing to make some of
Moon's non-essential improvements at this point. Someone needs to
decide how frozen the manual is on a number of these issues.
We need explicit rulings on these issues within the next couple of days.
The most critical thing is that each and every change or substantive
clarification that is made to excelsior must be noted in a separate file
of errata. What we can't do, at this point, is wait around for the next
edition and then have to grovel through every line of it to see what has
been changed. That saves you a couple of hours, but costs the rest of us
a week apiece.
If you want to rule on all these issues and maintain the complete
post-excelsior errata file in a publically visible place (CMUC, I
guess), that would be great. If you'd rather have me do it, more or
less in the spirit of the Memorial Day effort, that is OK too. Let me
know how you want to handle this.
Hope the editing goes well. I met at LOT of people at AAAI who wanted
to get their hands on Common Lisp, so the bandwagon lives; some of them
are getting impatient, however.
-- Scott
∂01-Oct-83 1501 RPG Comments on Excelsior manual
∂02-Sep-83 1018 Guy.Steele@CMU-CS-A Comments on Excelsior manual
Received: from SU-DSN by SU-AI with PUP; 02-Sep-83 10:17 PDT
Received: From CMU-CS-A by SU-DSN.ARPA; Fri Sep 2 10:00:51 1983
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 2 Sep 83 09:37:23 EDT
Date: 2 Sep 83 0047 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: fahlman@CMU-CS-C, rpg%su-ai@su-dsn, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, bsg%scrc-tenex@MIT-MC
Subject: Comments on Excelsior manual
<This includes all of Moon's message, with comments by SEF in pointy
brackets. Things that just need to be clarified and upon which I have
no strong opinion do not have a comment. >
[Comments by GLS are in square brackets.]
p. 25: integer and ratio are not an exhaustive partition of rational?
fixnum and bignum are not an exhaustive partition of integer? Yow!
Such possibilities for language extension...
[What kept me from making the partition exhaustive was the nagging feeling
that someday someone might want to adjoin representations of infinity
(positive and negative). Maybe this is a quibble, and we should describe
it as an exhaustive partition anyway. Comments?]
p. 26 (second to last paragraph): it says that an implementation may not
unilaterally add new subtypes to common. But since common includes all
types created by defstruct, anyone using defstruct is adding new subtypes
to common. I think this is just a wording problem, probably this has
to do with the word "exhaustive union" and you're trying to say that only
the Common Lisp committee can add new subtypes to common that are not
subtypes of the existing list of subtypes. But I'm not sure, which is
why this is included here.
[I think you have understood the intent; the wording does need to be fixed.]
p. 40: there is a typo in which the arguments to COERCE are given in the
wrong order, probably because you were reasoning by analogy from concatenate,
which appears in the same sentence. Since THE, MAP, and MERGE also put the
type first, I suggest that COERCE is broken and should be changed to put the
type first. However, this was rejected the last time I suggested it. Since
the manual is inconsistent, I suggest that it is only a clarication to change
the order of arguments now.
< No, there's code written that uses COERCE as documented, so if we
change it, it is a change. I'd let it be -- to swap it makes it more
consistent but less intuitive. >
[We already went around on this once, I think. Let it stand.]
p. 43 (third paragraph, parenthesized sentence): Does this mean that no
extensions to the evaluator are allowed, or that they have to use data
types that are not a subtype of common? This depends on what "Common Lisp
data object" means exactly.
[Sigh. I guess it should read "is an error", and make a remark about
permitted extensions, and the desirability of explicit error signalling.]
p. 48 (first sentence): &key keywords should not be required to be in the
keyword package, only encouraged to be. There are occasional reasons to
have private-packaged keyword-argument names. This applies to the second
paragraph on p.49 also.
< We have to balance this "occasional need" against the error checking
provided if we require these things to be keywords. I'd let it be. >
[Unless you can demonstrate the need more conclusively, I am inclined
to let it stand. It "must" be a keyword, and therefore it "is an error"
if it is not, so implementations may make the extension if desired.]
p. 63 (third paragraph): This is the first of several typos that think
that EQUAL compares all arrays element by element (it used to, but now it
only compares strings and bit vectors). I suggest the introduction of
a new function EQUALC ("equal components") that compares numbers and
characters the way EQUAL does, but compares arrays the way EQUALP does
(of course, when comparing strings the individual characters are compared
the way EQUAL does, case-dependently). Another typo is on p.195 (copy-seq).
< Just fix the typos. If Moon wants new equal functions, these are for
the second edition. I think we've got enough. >
[I strongly oppose the introduction of new functions at this time
without clear-cut demonstration of language inadequacy.]
p. 69: It would be difficult for us to enforce the restriction that funcalling
the result of SYMBOL-FUNCTION of a special form (not a macro) WILL signal
an error. I suggest that it IS an error.
< Yes, that sounds right to me. Checking for this could be more
expensive than useful. >
[Sigh. It should be zero cost for a properly arranged implementation,
but if you say so, I am willing to make it "is an error".]
p. 87: Declarations are not allowed at the beginning of the body of a COMPILER-LET,
I think. Certainly declarations of the variables being bound -at compile time-
would not be meaningful. It is probably best to require use of LOCALLY to
put declarations here. COMPILER-LET is not in the table on p.117.
< I agree. >
[Right.]
p. 103: In setting MULTIPLE-VALUES-LIMIT, what should I do about the fact
that on the LM-2 MULTIPLE-VALUE-PROG1 has a different limit on the number
of values than does everything else. Should I set MULTIPLE-VALUES-LIMIT
to the higher limit, and say that MULTIPLE-VALUE-PROG1 has a bug (hopefully
it signals an error if you exceed its limit), should I set MULTIPLE-VALUES-LIMIT
to the lower of the two limits, or should I make MULTIPLE-VALUE-PROG1 accept
more values (and hence be slower and more prone to stack-frame-overflow
errors). None of this applies to the 3600; no problems with multiple values
there.
< If an implementation has several values for one of these limits,
depending on fine-grained decisions, it should supply the most
restrictive limit. >
[Right.]
p. 112: Is it a requirement that redefining a special form globally with
a macro must work? Or is this just an example? I don't think it works
now in our implementation.
< Better not require this. >
[How about that it "is an error" to attempt to redefine a special form
in any way?]
p. 130: Is GENSYM required to return G7 rather than G0007, or is that
just an example? In either case there should be a rationale or
compatibility note. But there is also the technical issue of which it is.
< Can we leave this unbound? Nobody should depend on these names. If
not, I am in favor of G7. >
[For the sake of uniformity, I would rather bind the decision.
The four-digit business is partly influenced by the PDP-10, obviously.
It does have value in making the generated symbols more recognizable as such.
I would insist that the counter never "wrap around"; if you go above 9999
then you have to start using at least five digits, etc. I am inclined
to let the spec stand.]
p. 130: keywordp should be nil for all non-symbols, not an error. I.e.
keywordp should be a data type predicate, not a symbol operation.
< Right. This was already discussed. >
[Right.]
p. 141: the new-nicknames argument to rename-package should be &rest,
not &optional, for uniformity.
< I don't see how this furthers the cause of uniformity. I favor
&optional, though not passionately. >
[I don't see the uniformity either.]
p. 168: shouldn't the third value of decode-float and integer-decode-float,
the sign, be an integer (1 or -1) rather than a float? Same for float-sign
when given only one argument. Maybe there's a reason for making this be
a float, that I don't see and that isn't set forth in the manual.
< I don't care. >
[float-sign of two args needs to return a float. For uniformity
within float-sign, it therefore also returns a float with one arg.
decode-float's third value should be similar to the result of
float-sign. QED?]
p. 175: I feel that BYTE-SPECIFIER ought to be a data type for declaration
purposes (but an implementation is allowed not to support it as a data type
for discrimination purposes). Say that BYTE-SPECIFIER may or may not be
a subtype of NUMBER, depending on the implementation.
< Seems like a lot of fuss for no reason. But then, I've never like
byte specifiers at all. >
[Doesn't seem urgent enough to make a language change at this point.
Save it for second edition.]
p. 189: I don't like MAKE-CHAR, since its arguments are not consistent
with the other MAKE-xxx functions, and the function seems quite redundant
with CODE-CHAR. I suggest making CODE-CHAR accept characters as well
as integers as its first argument, or else making CHAR-BITS and CHAR-FONT
SETF'able.
< Not a bad suggestion, but not worth unfreezing for. >
[Agreed.]
p. 191: In an implementation that doesn't have "super bits", is
(char-bit char :super) always false or is it an error? This may just be
a matter of clarity of explanation.
< Whatever.>
[Good quesiton. I don't care. Recommendations?]
p. 199 (replace): What happens if sequence1 and sequence2 are not the same
object, but share storage because they are lists with shared substructure
or because one of them is a displaced array? I propose that the result
be undefined, since it is expensive to check for and not a very useful
case to support.
< Yes, let's make this undefined. >
[Okay, twist my arm.]
p. 213: PUSHNEW takes the same keyword arguments as ADJOIN (probably this
is only a typographical error that no keyword arguments are listed).
< Yes, this must be a typo, right? >
[Yes, a typo. Will fix.]
p. 216 (SUBLIS): are the cars of the alist elements required to be symbols,
as in Maclisp and implied by the first sentence of SUBLIS's description,
or are any objects acceptable (i.e. SUBLIS just acts as if it calls ASSOC
its first argument and its keywords)? I prefer the latter.
< Yes, the latter is best, and this "clarification" would not break any
code. I don't know what our implementation does right now. >
[Yes, the latter. This was a "thinko" as I was transcribing some other
definition of sublis.]
p. 229: What happens when array B is displaced to array A and their element
types are not the same? Okay for this to be an error, but not okay to signal
an error (we want it as a language extension).
< "It is an error", I guess. Let each implementation worry about what
to do here. Can't win in protable code. >
[Is an error. I meant to say that and forgot.]
p. 230: What happens when array-total-size-limit is a function of the element
type? Should this constant be set to the minimum over all element types?
< Yes, the minimum. >
[Right.]
p. 233: Is this feature that a third argument of t to the bit functions means
to use the first argument as the third argument really a win? Maybe one should
simply pass the first argument twice in this case. I don't feel very strongly
about this, but it seems like a kludge.
< We discussed this, I think (maybe just you and I), and decided that T
was the most convenient convention. Passing the bit-vector twice often
requires a let or something equally awkward. Anyway, it's too late for
such twiddles. >
[Ugly, but let it stand.]
p. 241 (STRING): It doesn't mention using STRING to coerce a character to
a 1-element string. My vague memory is that this was an accepted change to
the language (at the time character objects were made mandatory and the
ability for an implementation to use integers instead of characters was
removed).
< I don't remember this, but don't care either way. Flag it as a
change, though, if this is added. >
[I suppose this is okay, and implies that all the standard string
functions will accept characters in the cases that they accept symbols
in place of strings.]
p. 248: The "named structure" stuff in defstruct is confused. The term
"named" is being used to mean two different things. There are two kinds
of defstructs: One is a subtype of STRUCTURE; TYPEP and TYPE-OF know how
to find the type name symbol for any object that is a structure. In some
implementations a structure is a vector with its type name in element 0,
and a magic "I am a structure" bit set. In other implementations, STRUCTURE
is not a subtype of any other COMMON type (e.g. in NIL STRUCTURE is
a subtype of EXTEND). When making this type of defstruct, the user does
not and cannot know exactly what type defstruct will make, since it is
implementation-dependent. The other kind of defstruct is one where the user
has requested a specific data type, such as VECTOR or LIST. In this case
TYPEP and TYPE-OF cannot be guaranteed to work (and in all implementations
I know of they won't work). In this second kind of defstruct, "named" just
means that defstruct automatically allocates a structure slot containing
the name symbol.
I suggest that (:type structure) mean the same as not specifying :type,
namely an object for which TYPE-OF and TYPEP "work". :unnamed is illegal
in connection with this, and :named is redundant. I suggest then that
structure be made a legal type specifier again, for consistency with this.
It means only "defstructs of the first kind."
For the non-structure :types, :unnamed is redundant.
Hence I suggest that :unnamed be flushed.
< Glurk! Too bad we couldn't all have decided that defstructs were
general vectors, period. Do whatever it takes. >
[Modified proposal: flush :unnamed, but do not put in (:type structure);
just say that you get a type-1 defstruct if you don't have a :type
clause.]
p. 249: "Moreover, astronaut will have its own access functions for
components defined by the person structure." Did we really agree to
this? I don't recall ever hearing of this before. It is incompatible
with previous usage, and seems useless to me.
< I never did understand this stuff. Probably nobody would notice a
change here. >
[It's not incompatible and it's not useless; it allows the user to
state more exactly what is going on. The selectors astro-name and
person-name are identical when applied to an astronaut; however,
pserson-name may be applied to any person, astronaut or not,
whereas it is an error to use astro-name on anything but an astronaut.
Admittedly the advantages of this requirement are primarily stylistic.
Implementationally, it may be faster for astro-name to check that
an astronaut is an astronaut than for person-name to check that
an astronaut is a person, by a matter of a very few cycles, depending
on the implementation. This last is a minor quibble.]
p. 250: I suspect that the :eval-when option to defstruct is unnecessary
and should be removed. I think it was put in to get around a bug in the
Lisp machine compiler that was fixed years ago. I could be misremembering.
< I never understood why this was needed. Looks to me like you could
just put EVAL-WHEN around the outside. >
[I agree -- flush it.]
p. 254: I suspect that *EVAL is called only by "FEXPRs" and should be deleted
from the white pages. It exists internally in the evaluator, of course.
< I argued earlier that we should flush this, since we can't tell the
user what the environment looks like or where to get one. Seems
ill-defined as is. >
[I included it for use by hook functions, but I suppose one can just
use the evalhook function and feed it two nil's. The slight overhead
is a couple of extra binds. So what. Flush *eval.]
p. 257 (second and fourth paragraphs, and parentheses in the first paragraph):
We agreed to change the rules for * to be consistent with what was printed,
rather than aligned with +, but the manual wasn't updated.
< I am by now totally confused about what we agreed to. If you can
spell it out, I'll try to implement it. >
[I remember what was agreed to. + is as before. *, **, *** are updated
every time a result is printed, whether it is the only result or one of
several. If an evaluation produces zero values, then * does not change.
/, //, /// are updated when the results of an evaluation are printed,
however many (possibly zero) there are; if the computation is aborted,
/ is not updated. Example:
(gensym) ;Interaction 1
G3141
(cons 'a 'b) ;Interaction 2
(A . B)
(hairy-loop)↑G ;Interaction 3
>>>> Moby quit: you are outside a small building at the end of a road.
(floor 13 4) ;Interaction 4
3
1
; At this point we have:
; +++ => (cons 'a 'b) *** => (A . B) /// => (G3141)
; ++ => (hairy-loop) ** => 3 // => ((A . B))
; + => (floor 13 4) * => 1 / => (3 1)
Does that look right?]
p. 263: are INPUT-STREAM-P and OUTPUT-STREAM-P type predicates like streamp,
or is it an error to call them on objects that aren't streams? This may
just be a textual clarity issue. INPUT-STREAM and OUTPUT-STREAM are not
in Table 4-1.
< These don't want to become first-class data-types, so maybe make it an
error to call them on non-streams. >
[Right.]
p. 264 (last sentence): The file is only deleted if it was newly-created.
Not if appending or overwriting an existing file.
[Right.]
p. 279: When #+/#- skips a form, certain read errors should be suppressed.
This is necessary in order to use #+ to conditionalize code that runs in
multiple implementations, or multiple environments with different packages
present. The things to be suppressed include forms after #. and #, ,
floating-point exponent range errors, qualified name errors (no such package,
no such external symbol), #n=. (#+lispm #1= <a> #+spice #1= <b> <c> #1#)
should work and not complain that the "tag" 1 is used twice, except if
the "lispm" and "spice" features are both true.
< Ugh. He's right. I see now that we should have made these delimited
like #| so that we wouldn't have to call read at all, but can just skip
over stuff. Any chance that we can define this somehow so that it is
easy to scan over what should be skipped -- one atom or balanced parens? >
[It's not that easy. There is a question of whether or not one should invoke
user-defined macro-character definitions. I am inclined to say yes; ideally
such a function could have access to flag saying whether you are ignoring
or not. For now, let's carefully define what does and does not happen
when you're skipping. In particular, the syntax of tokens made up of
constituents is completely unchecked. (This is one reason why I wanted
this simplified theory of constituents so you could find the boundaries
of tokens before interpreting their syntax.)]
p. 281: What does the from-readtable argument to COPY-READTABLE default to?
The manual directly contradicts itself. I suggest that it default to the
value of *READTABLE*, but that NIL mean "the standard Common Lisp readtable,
i.e. the value of *READTABLE* before any side-effects on the variable or
on the readtable were perpetrated."
< Sounds good. >
[Okay.]
p. 284 (last paragraph): When the printer decides whether a symbol's name
must be slashified because it looks like a number, is this decision dependent
on the value of *READ-BASE* or the value of *BASE*. In other words, what
controls whether the symbol FF prints as FF or \FF? I suggest *BASE*.
< We've already had a fight over this within the Slisp group. I don't
care what we do as long as it gets nailed down. >
[Arrghhh! It comes back to haunt us. This is one the original reasons
for not introducing IBASE, and for requiring #nR syntax for supra-decimal
radices; it guaranteed that no number began with a letter. Foo.
Yes, *BASE* is the one to use.]
p. 287: What's the initial value of *PRINT-PRETTY* ? I suggest NIL.
< NIL is OK. I'd rather leave it to the implementation. >
[I agree with Scott.]
pp. 290, 296: "Ascii streams" should be called "Character streams", since
the character code in use is not necessarily Ascii.
< Yeah. >
[Right.]
pp. 290, 296: I'd still like to flush the feature that T and NIL as output
streams have special meanings. This is a holdover from Maclisp. The main
problem with this feature is that FORMAT uses T and NIL to mean something
incompatible with this.
< Good suggestion, but probably too late. >
[Sigh. I think we don't dare change this now.]
p. 290: Recursive reads need control over eof handling. Having the eof-errorp
of the top-level call to read controls what happens isn't good enough. For
example, the semicolon reader macro has to read until a Return character or
EOF; it should not be an error for a comment to end at end-of-file without
a carriage return (it is all too easy for a user to forget to put in the
carriage return). I suggest that in recursive reads, eof-errorp = nil means
return eof-value from the inner call to read regardless of the top-level read's
arguments, and eof-errorp = t means look at the top-level read's arguments,
and either signal an error or throw back to the top-level read and return
its eof-value, but in neither case return from the inner read. Then fix
all examples that say (READ stream NIL NIL T) to be (READ stream T NIL T).
< Sounds OK. Some would view this as a change, but the present scheme
may be unworkable.>
[You're right; let's do it.]
p. 292: READ-DELIMITED-LIST should allow comments as well as whitespace
between the last object and the delimiter.
< OK with me. >
[Yes. The wording needs to be fixed.]
p. 293 (READ-LINE): What happens if end-of-file terminates an empty line
(the second to last sentence says that when end-of-file terminates
a non-empty line, the line and T are returned)? Should "" and T be
returned, or should the function take eof-errorp and eof-value arguments?
Zetalisp's READLINE function does the latter.
< Whatever. >
[What Zetalisp does, I guess.]
p. 294 (READ-FROM-STRING): Maybe the two optional arguments should be
keywords, to make things more uniform. I suggest that :EOF-ERROR
should default to true unless :EOF-VALUE is specified and :EOF-ERROR
is not specified. This makes one wonder whether there should be two
keywords or one.
< Too late. >
[Let it stand.]
p. 297 (WRITE-CHAR): Do we really want this to return NIL? All the
other writers return what they wrote (actually, their first argument,
which is not necessarily exactly what they wrote).
< Whatever. >
[Sigh. Okay, do it.]
p. 298 (first paragraph): Regardless of what characters TERPRI on a
stream outputs to the physical device, it must be required that
(WRITE-CHAR #\RETURN stream) writes exactly the same characters. Or
is this not true, in which case you better say so very explicitly.
< Seems to me that TERPRI does the locally tasteful thing, while
WRITE-CHAR does just what you tell it. Maybe we should make a point
of this.>
[There are nasty issues on both sides of this. I think I agree with
Scott: to get a proper line termination one should do TERPRI or
format's ~%. Implementations may or may not choose to supply LF after
RETURN for certain kinds of streams? Sigh.]
p. 298 (last line): I assume it's a typo that WRITE-BINARY-OBJECT
can only write arrays of integers, not arrays of all numbers, since
it can write all kinds of numbers as scalars.
< ??? >
[Well, you have to stop somewhere. How about symbols? Hashtables?
I'm inclined to let it stand for now.]
p. 299: ~F appears to require negative prefix parameters, which previous
format operators didn't require. Say in the fourth paragraph on page 299
that minus signs may be used in prefix parameters.
[Sigh. You're right -- the k parameter. The *right* thing, after doing
this, would be to simplify some other things, such as ~:* => ~-1*.
However, we'll have to let that stand.]
p. 303: I think that if the third prefix parameter to ~E is omitted,
the exponent should use as many digit positions as required, rather than
using exactly 2. This would make e be treated the same as w and d.
[Okay.]
p. 305: I suggest the following exception handling in ~$:
If the arg is too small, it is taken to be zero.
If the arg is too large, it is printed with an exponent. If w is not
specified, too large means something like 40 or 64 or 100 digits; this
could be left to the implementation.
If the arg is rational, it is first coerced to a single-float (see below).
If the arg is not a number, or complex, it is printed in ~wD format.
[Okay.]
pp. 302-305: I suggest that when a rational is printed in ~F, ~E, ~G,
or ~$ format, an implementation be permitted either to coerce it to
single-float or to do something that retains more precision and doesn't
risk exponent overflow, at its discretion. "Something" could be
coerce to long-float or could be format it "exactly", except that if
the number of digits is not specified and a ratio that does not have
an exact decimal representation (e.g. 1/3) is specified, a finite
number of digits must be printed.
[Okay.]
p. 306: ~G should be replaced by ~@*.
[Right.]
p. 307: The example of ~? is not consistent with the text. Possibly this
is a typo and the format string should have started ``"~1{~?~}~%~V...'',
but I'm not sure. If so, be sure to point out that the ~? is expanded
outside of the iteration caused by the braces, and before the braces
pick up their argument (the list to iterate over). This is the same
as use of ~V inside of braces.
[~? was ill-specified. I think it needs to have a @ modifier similar
in effect to that for braces.]
p. 311: Does ~↑ with three prefix parameters do inclusive (<=) or
exclusive (<) comparison? Ugh, bletch!
[Inclusive.]
p. 312: I think we agreed to change the arguments to Y-OR-N-P and
YES-OR-NO-P to be ``&optional format-string &rest format-args''. This
is compatible in the usual case where one argument is supplied and it
doesn't contain any tildes, and is much more useful than specifying a
stream; one never wants to change the stream locally, rather than
globally by binding *QUERY-IO*.
< I don't recall this agreement, but it sounds like a very good
suggestion, probably worth accepting even now. >
[Right.]
p. 317: Some file systems lack devices, types, or versions, hence you
need a value for these components in pathnames for those file systems.
The Lisp machine uses the keyword :UNSPECIFIC for this. This is different
from NIL, which means that the component was not specified by the pathname
and can be supplied by merging. Most file systems either never allow
a given component to be :UNSPECIFIC, or require it always to be :UNSPECIFIC,
but there are some where this is not the case. ITS, for example, can
have either a type or a version, but not both. When it has a version, the
type is :UNSPECIFIC. When it has a type, the version is :UNSPECIFIC.
When it has neither, both components are NIL. It may be possible to
get rid of :UNSPECIFIC and use NIL both to mean "this component was
not specified" and to mean "this component cannot be specified", but
this would require more complexity in the merging process.
< Since the current file chapter is pretty confused, and this is
everyone's first look at it, I don't regard it as frozen. Adding
:UNSPECIFIC in the sense of "Illegal component in this type of file
system" sounds OK, but the name is damned confusing. How about
:NOT-USED-IN-THIS-SYSTEM or some such? >
[I think NIL can be used for both purposes.]
p. 318: TRUENAME of a stream should be the truename of the file actually
open. This cannot be done by first converting the stream to a pathname
then taking the truename of that. File system operations performed after
the stream was opened might have changed the mapping of the stream's pathname
into a truename, for instance if the version of the stream's pathname
is :NEWEST and a newer file was created.
< Right. >
[Right.]
p. 319: If TRUENAME returns NIL if there is no such file, it is identical
to PROBE-FILE. If it quietly returns its argument, it is a liar. Probably
best to error. Then PROBE-FILE is TRUENAME except that it returns NIL for
a file-not-found error (but not for other errors such as directory-not-found,
file name illegal, or foreign host not responding).
< Well, that would settle the query -- we would have both an
error-signalling form and one that returns NIL if the file isn't there.
I'd prefer to have truename return NIL and just flush PROBE-FILE, but I
don't really care. >
[Let it error out.]
p. 319: Flush the stuff about "conventions" in parse-namestring. parse-namestring
should take a junk-allowed argument that defaults to nil, like parse-integer.
Shouldn't start and end be keywords, like for most other functions that take
such arguments? By analogy with parse-integer, all of the arguments to
parse-namestring except the first should be keywords.
< Well, I'm not sure the analogy holds, but I don't really care much. >
[Right.]
p. 320 (pathname-plist): I don't think it is wise to put property lists on
pathnames in Common Lisp. Especially when you don't say anything about
whether or not pathnames are "interned", i.e. does parse-namestring called
twice with the same arguments return two pathnames that share the same property
list, or two distinct pathnames, or is this implementation-dependent. Better
not to include any operations that perform side-effects on pathnames in Common
Lisp, so that only EQ can tell whether they are "interned." This means you
have to define what EQUAL means for pathnames. I see that page 63 says that
EQUAL compares pathnames by components, which is good, but this should be
mentioned in the pathname chapter also. EQL on pathnames should be the same
as EQ, and hence not useful, and this should be mentioned in the pathnames
chapter.
< I would say that parse namestring called twice produces two distinct
pathname objects with the same components. If you put properties on one
of them, they don't magically appear on the other. So what? I don't
see this causing any trouble in normal use. One can always use a
hashtable to intern these by hand if it matters. I agree that EQL is
like EQ and that EQL probably looks at components. >
[I think that last EQL of Scott's should be EQUAL. Yes, let's nuke
the pathname plists.]
< By the way, there seems to be no way to copy a pathname. In the
compiler, I want to copy the input pathname and then bash the type field
of the copy to the LAP or FASL. How am I supposed to do this? I
couldn't figure out how to do it with MERGE-PATHNAMES alone. Do we need
COPY-PATHNAME ? >
[You're not allowed to bash pathnames. Use MERGE-PATHNAMES:
;Change TYPE component of pathname X to BAZ.
(merge-pathnames (make-pathname :host (pathname-host x) :type "BAZ")
x)
Does that do it?]
p. 321: INIT-FILE-PATHNAME should take an optional argument that is the file
type. Whether this argument affects the result depends on the host (not
on the Common Lisp implementation!). To be consistent with FS:INIT-FILE-PATHNAME
in Zetalisp, the type argument should come before the host argument.
[Okay by me; however, it would seem that the type would more logically
follow the host, as its presence or absence depends on the host.]
p. 322 (second paragraph): Since all pathnames include a host, merging cannot
be responsible for putting in the default device. Pathname parsing must
do this; parsing a string that specifies a host puts in a device component,
which is the default file device unless the string specifies an explicit
device. Also the description of merging, and much of the rest of the pathname
chapter, doesn't know that MERGE-PATHNAME-DEFAULTS was flushed (over my mild
protests that both MERGE-PATHNAMES and MERGE-PATHNAME-DEFAULTS are useful).
< Ah, that clarifies something that was confusing to everyone. I
wouldn't object to a return of MERGE-PATHNAME-DEFAULTS, but we need a
better name. >
[Suits me.]
pp. 322-324: Logical pathnames are useless without a standardized syntax. The
logical pathname system here is based on an obsolete specification of logical
pathnames in the Lisp machine, hence is not attractive to us. I suggest that
logical pathnames not be included in Common Lisp this time around; they can
be standardized later when they are better understood.
< Amen. Nobody would mourn their loss. >
[Right.]
p. 325 (:element-type standard-char): What happens if the input file in fact
contains a non-character? Is this a case of "is an error" or "signals an
error"? What happens if the user calls WRITE-CHAR with a non-standard character?
What about READ? Are any strings whose printed representation is read from a
stream with :element-type standard-char guaranteed to contain only standard chars?
If READ-CHAR and WRITE-CHAR are required to check and signal an error, does this
requirement extend to :element-type string-char as well? How about READ-BYTE
and WRITE-BYTE checking that the bytes fit in the byte size declared by the
element-type? The best thing for right now is probably to leave the specification
loose and let implementations decide how much error checking they want to have.
< How about flushing this element-type for files? Is this confusing
crock really useful? >
[Flush it.]
p. 326: :if-exists :rename and :if-exists :rename-and-delete, like :if-exists
:supersede, should be encouraged not to affect the existing file until the
stream is closed, and not to affect it at all if the stream is closed in
abort mode. Should this be required rather than encouraged? Encouraged is
probably better since file systems vary so widely in their capabilities.
Explain what :if-exists :supersede means more precisely. Is it permissible
for this to mean the same as :rename, or :rename-and-delete? Note that
:supersede rather than :error is the default when the file system does not
have versions, since the pathname component can't be :newest in this case.
< Yes, encouraged. >
[Encouraged with a very big stick, or perhaps a cattle prod.]
p. 327: clarify that in :if-does-not-exist :create mode, "proceed as if
it had already existed" does not include any processing directed by the
:if-exists argument. Someone here was confused by this.
[Yes.]
p. 328 (rename-file): I think we agreed that values saying what was done,
rather than t, should be returned. The Zetalisp RENAMEF function returns
three values, which are the second argument (new-name) after merging with
the first argument so that renaming leaves unspecified components unchanged,
the truename before renaming, and the truename after renaming.
< I do seem to recall this. >
[Yes.]
p. 328 (rename-file and delete-file): if it is an error to specify a pathname
containing a :wild component, what about nil components? Do they default
by merging with some default defaults, or are they an error?
[How about an error? We should be very cautious with these. Remember the
time some poor random deleted about 1/3 of MC's files because of a missing
set of parens?]
p. 328 (file-creation-date): People here find the word "creation-date"
(used by Zetalisp) very ambiguous and confusing. I suggest that this
function be named file-write-date or file-written-date (depending on our
grammatical preferences).
< 4004 B.C. for all files. But seriously.... >
[Fine.]
p. 328 (file-position): This can't work easily when there is character
set translation (including translation of the Return character to a
VAX/VMS or OS/360 record boundary). Should file-position be defined to
return NIL when the element-type of the stream is one that requires such
translation, or should it be required to return the equivalent number
of READ-CHAR/WRITE-CHAR operations, or should it be required to return
a number in the units in which the file is actually read or written?
This is a probably for file-length, too.
file-position with two arguments should use :start and :end rather
than nil and t (or do I mean rather than t and nil? That's the point.)
Bi-directional streams should have separate read and write positions,
shouldn't they?
< Good points. Maybe encourage the file-position to indicate READ-CHAR
equivalents, but allow NIL if it can't hack this in certain crockish
systems. >
[How about just requiring that it be a monotonically increasing function
of the number of READ-CHAR/WRITE-CHAR operations; that is, xxx-CHAR always
increments it by some positive integer but not necessarily by 1?]
p. 329: I don't approve of making the filename argument to LOAD
optional. Am I overruled by a concensus of the committee? I don't
recall this ever being discussed.
< I don't recall this being discussed either, but thought that I might
have slept through this. I agree strongly with MOON that the filename
arg to LOAD should be required, and the filename argument to
COMPILE-FILE as well. I really don't like this
*LOAD-SET-DEFAULT-PATHNAME* stuff. I guess it is reasonable to hold
that we're too late on this, however. >
[I'm inclined to let it stand.]
p. 335: The string subform of CHECK-TYPE is evaluated.
[Right.]
p. 335: The syntax for ASSERT hasn't been updated to the new syntax
we agreed on, which flushes the kludgey use of string as a delimiter.
string is evaluated now.
< Right, as agreed. >
[Right.]
p. 347: Shouldn't the symbols on *FEATURES* be keywords? If even
implementation-specific elements of *FEATURES* go in the LISP package,
they can cause accidental sharing. In general implementations have
to be careful about adding their own symbols to the LISP package,
since this could make some programs become unportable (until they
do a SHADOW).
Note that one does not write a colon in the #+ (or #-) syntax; all
symbols in that syntax are assumed to be keywords.
< No, this was a ballot item earlier, and we decided not to make these
keywords. >
[Scott is correct.]
∂01-Oct-83 1502 RPG Comments on Excelsior manual
∂02-Sep-83 1206 Moon%SCRC-TENEX@MIT-MC Comments on Excelsior manual
Received: from SU-DSN by SU-AI with PUP; 02-Sep-83 12:06 PDT
Received: From MIT-MC by SU-DSN.ARPA; Fri Sep 2 12:07:44 1983
Received: from SCRC-SCHUYLKILL by SCRC-TENEX with CHAOS; Fri 2-Sep-83 14:41:21-EDT
Date: Friday, 2 September 1983, 14:41-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Comments on Excelsior manual
To: Guy.Steele@CMU-CS-A, fahlman@CMU-CS-C, rpg%su-ai@SU-DSN,
moon%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC, bsg%SCRC-TENEX@MIT-MC
In-reply-to: The message of 2 Sep 83 00:47-EDT from Guy.Steele at CMU-CS-A
Date: 2 Sep 83 0047 EDT (Friday)
From: Guy.Steele@CMU-CS-A
p. 25: integer and ratio are not an exhaustive partition of rational?
fixnum and bignum are not an exhaustive partition of integer? Yow!
Such possibilities for language extension...
[What kept me from making the partition exhaustive was the nagging feeling
that someday someone might want to adjoin representations of infinity
(positive and negative). Maybe this is a quibble, and we should describe
it as an exhaustive partition anyway. Comments?]
Good point. Leave it the way it is, and add a footnote about integer infinities.
p. 48 (first sentence): &key keywords should not be required to be in the
keyword package, only encouraged to be. There are occasional reasons to
have private-packaged keyword-argument names. This applies to the second
paragraph on p.49 also.
< We have to balance this "occasional need" against the error checking
provided if we require these things to be keywords. I'd let it be. >
I see no additional error checking gained by requiring keyword argument names
to be keyword symbols. There is already error-checking that only the correct
keyword argument names are used, unless the use specifically disables the error
checking with allow-other-keys.
[Unless you can demonstrate the need more conclusively, I am inclined
to let it stand. It "must" be a keyword, and therefore it "is an error"
if it is not, so implementations may make the extension if desired.]
I won't press the point now, as long as it doesn't "signal an error."
p. 141: the new-nicknames argument to rename-package should be &rest,
not &optional, for uniformity.
< I don't see how this furthers the cause of uniformity. I favor
&optional, though not passionately. >
[I don't see the uniformity either.]
This is the uniformity:
"rename-package takes a package and any number of names (at least one) as
arguments. All the package's current names are discarded and the specified
names are made to be the names of the package. The first name specified
is preferred for output, but all of the names are accepted on input."
Actually in our system the first name is preferred for output when printing
the package object, but the shortest name (unless the user specifies otherwise)
is preferred for printing qualified names of symbols in the package.
p. 168: shouldn't the third value of decode-float and integer-decode-float,
the sign, be an integer (1 or -1) rather than a float? Same for float-sign
when given only one argument. Maybe there's a reason for making this be
a float, that I don't see and that isn't set forth in the manual.
[float-sign of two args needs to return a float. For uniformity
within float-sign, it therefore also returns a float with one arg.
decode-float's third value should be similar to the result of
float-sign. QED?]
I see. Put a @rationale footnote to this effect in the manual.
p. 250: I suspect that the :eval-when option to defstruct is unnecessary
and should be removed. I think it was put in to get around a bug in the
Lisp machine compiler that was fixed years ago. I could be misremembering.
< I never understood why this was needed. Looks to me like you could
just put EVAL-WHEN around the outside. >
[I agree -- flush it.]
Bawden explained this to me. The problem is that
(eval-when (load) (defstruct s a))
expands into
(eval-when (load)
(eval-when (compile load eval)
(defstruct-internal 's '(a))
(defstruct-define-constructor 'make-s 's))
(defun s-a (s)
(declare (open-codable))
(%structure-reference s 1)))
or something like that (I have written the above in a real bastardized language)
and the outer eval-when does not stop the inner eval-when from defining things
at compile time. The real problem is with eval-when, since there is no way to
distinguish "eval this at load time ONLY" from "eval this normally". A better
way than the :eval-when option, which everyone agrees is a kludge, would be to
make it possible for defstruct to find out what eval-when environment it is
being expanded in (e.g. eval-when could imply compiler-let of a specified
variable name). In the absence of that, we have to decide whether to leave
the :eval-when feature in, or decide that the case it fixes is obscure and
leave it out of the manual (like dozens of other more useful defstruct features).
Either way is okay with me, probably default to leaving it in I guess.
p. 257 (second and fourth paragraphs, and parentheses in the first paragraph):
We agreed to change the rules for * to be consistent with what was printed,
rather than aligned with +, but the manual wasn't updated.
[I remember what was agreed to. + is as before. *, **, *** are updated
every time a result is printed, whether it is the only result or one of
several. If an evaluation produces zero values, then * does not change.
/, //, /// are updated when the results of an evaluation are printed,
however many (possibly zero) there are; if the computation is aborted,
/ is not updated. Example:
(gensym) ;Interaction 1
G3141
(cons 'a 'b) ;Interaction 2
(A . B)
(hairy-loop)↑G ;Interaction 3
>>>> Moby quit: you are outside a small building at the end of a road.
(floor 13 4) ;Interaction 4
3
1
; At this point we have:
; +++ => (cons 'a 'b) *** => (A . B) /// => (G3141)
; ++ => (hairy-loop) ** => 3 // => ((A . B))
; + => (floor 13 4) * => 1 / => (3 1)
Does that look right?]
Interesting. We would have *** => G3141, ** => (A . B), and * => 3,
on the grounds that usually only the primary value is interesting, and to
get at other values you have to use /. But saying that -each- value
printed pushes the * history sounds reasonable too. I can accept either
of these. Does anyone have a strong opinion about this?
p. 298 (first paragraph): Regardless of what characters TERPRI on a
stream outputs to the physical device, it must be required that
(WRITE-CHAR #\RETURN stream) writes exactly the same characters. Or
is this not true, in which case you better say so very explicitly.
< Seems to me that TERPRI does the locally tasteful thing, while
WRITE-CHAR does just what you tell it. Maybe we should make a point
of this.>
[There are nasty issues on both sides of this. I think I agree with
Scott: to get a proper line termination one should do TERPRI or
format's ~%. Implementations may or may not choose to supply LF after
RETURN for certain kinds of streams? Sigh.]
This is a real can of worms I guess. It is vital that the manual include
a discussion of this, since otherwise every implementation will go off in its
own incompatible direction. There are two possibilities: either Common
Lisp hides local strange end of line conventions under the #\Return character,
or it doesn't attempt to deal with this. Naturally I advocate the former,
since we already bit this bullet years ago, and I suggest that if one wants
to do device-dependent controls of a terminal one opens it with an element
type other than character. Is the value of
(= 3 (length "a
b")) permitted to be T in some implementations and NIL in others? Note that
Common Lisp has already specified that record-oriented implementations can't
expose their native convention in the language, but must instead have a
#\Return character (the character is standard, not optional).
I can accept the language specifying it either way, reluctantly perhaps, but
the language -must- specify it. If our goal is portability, we should
hide local vagaries under #\Return.
p. 298 (last line): I assume it's a typo that WRITE-BINARY-OBJECT
can only write arrays of integers, not arrays of all numbers, since
it can write all kinds of numbers as scalars.
[Well, you have to stop somewhere. How about symbols? Hashtables?
I'm inclined to let it stand for now.]
I think you missed my point. One can write-binary-object an integer, an
array of integers, or a float, but one cannot write-binary-object an array
of floats. Surely this is not intentional, since most people who use
floats are likely to use arrays of them, and if you support arrays at all
arrays of floats are no harder than arrays of integers.
p. 307: The example of ~? is not consistent with the text. Possibly this
is a typo and the format string should have started ``"~1{~?~}~%~V...'',
but I'm not sure. If so, be sure to point out that the ~? is expanded
outside of the iteration caused by the braces, and before the braces
pick up their argument (the list to iterate over). This is the same
as use of ~V inside of braces.
[~? was ill-specified. I think it needs to have a @ modifier similar
in effect to that for braces.]
I can't see how the @ modifier for ~{ could make sense for ↑?; it controls
whether the arguments iterated over are all the rest of the arguments or
the elements of a list passed as a single argument. ↑? doesn't deal in
arguments; it simply inserts a string into the control string (one could
presumably do the same thing with CONCATENATE before calling FORMAT).
p. 319: If TRUENAME returns NIL if there is no such file, it is identical
to PROBE-FILE. If it quietly returns its argument, it is a liar. Probably
best to error. Then PROBE-FILE is TRUENAME except that it returns NIL for
a file-not-found error (but not for other errors such as directory-not-found,
file name illegal, or foreign host not responding).
< Well, that would settle the query -- we would have both an
error-signalling form and one that returns NIL if the file isn't there.
I'd prefer to have truename return NIL and just flush PROBE-FILE, but I
don't really care. >
[Let it error out.]
Either erring out or not having both TRUENAME and PROBE-FILE would be okay with me.
p. 320 (pathname-plist):....
< By the way, there seems to be no way to copy a pathname. In the
compiler, I want to copy the input pathname and then bash the type field
of the copy to the LAP or FASL. How am I supposed to do this? I
couldn't figure out how to do it with MERGE-PATHNAMES alone. Do we need
COPY-PATHNAME ? >
[You're not allowed to bash pathnames. Use MERGE-PATHNAMES:
;Change TYPE component of pathname X to BAZ.
(merge-pathnames (make-pathname :host (pathname-host x) :type "BAZ")
x)
Does that do it?]
Clumsily, but it does do it. We have a :NEW-PATHNAME message for this purpose,
which takes the same arguments as MAKE-PATHNAME and returns a pathname which is
like the one that receives the message, as modified by the keywords. You could
also make the component accessors PATHNAME-HOST .. PATHNAME-VERSION be SETF'able;
they would work like LDB, since pathnames are not modifiable. Scott's specific
example is the main use of MERGE-PATHNAME-DEFAULTS, but of course that doesn't
solve the general problem of making a pathname which is "like this other pathname
except." You could also add one more keyword to MAKE-PATHNAME, with a name
like :PATHNAME or :FROM-PATHNAME, which supplies all components except those
specified explicitly (if this argument is not supplied, all unspecified components
are NIL as before).
I expect all this pathname stuff will be revised in a second go-around on
Common Lisp anyway.
p. 321: INIT-FILE-PATHNAME should take an optional argument that is the file
type. Whether this argument affects the result depends on the host (not
on the Common Lisp implementation!). To be consistent with FS:INIT-FILE-PATHNAME
in Zetalisp, the type argument should come before the host argument.
[Okay by me; however, it would seem that the type would more logically
follow the host, as its presence or absence depends on the host.]
I don't feel strongly about this, but the host argument is almost always omitted
and allowed to default to the "current" or "login" host; this suggests it should be last.
p. 328 (file-position): This can't work easily when there is character
set translation (including translation of the Return character to a
VAX/VMS or OS/360 record boundary). Should file-position be defined to
return NIL when the element-type of the stream is one that requires such
translation, or should it be required to return the equivalent number
of READ-CHAR/WRITE-CHAR operations, or should it be required to return
a number in the units in which the file is actually read or written?
This is a probably for file-length, too.
file-position with two arguments should use :start and :end rather
than nil and t (or do I mean rather than t and nil? That's the point.)
Bi-directional streams should have separate read and write positions,
shouldn't they?
< Good points. Maybe encourage the file-position to indicate READ-CHAR
equivalents, but allow NIL if it can't hack this in certain crockish
systems. >
[How about just requiring that it be a monotonically increasing function
of the number of READ-CHAR/WRITE-CHAR operations; that is, xxx-CHAR always
increments it by some positive integer but not necessarily by 1?]
Okay. I think we should specify that on binary streams, if READ/WRITE-BINARY-OBJECT
is not used, the file position exactly equals the number of READ-BYTE / WRITE-BYTE
operations.
For the items not included in this message, what Guy said is acceptable to me
(sometimes I'm enthusiastic, sometimes I'm not).
∂01-Oct-83 1502 RPG More comments on excelsior
∂02-Sep-83 2131 FAHLMAN@CMU-CS-C.ARPA More comments on excelsior
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Sep 83 21:31:23 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 3 Sep 83 00:32:36-EDT
Date: Sat, 3 Sep 1983 00:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: moon%SCRC-TENEX@MIT-MC.ARPA, steele@CMU-CS-C.ARPA
Cc: rpg@SU-AI.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA, bsg%SCRC-TENEX@MIT-MC.ARPA
Subject: More comments on excelsior
p. 141: the new-nicknames argument to rename-package should be &rest,
not &optional, for uniformity.
< I don't see how this furthers the cause of uniformity. I favor
&optional, though not passionately. >
[I don't see the uniformity either.]
This is the uniformity:
"rename-package takes a package and any number of names (at least one) as
arguments. All the package's current names are discarded and the specified
names are made to be the names of the package. The first name specified
is preferred for output, but all of the names are accepted on input."
Actually in our system the first name is preferred for output when printing
the package object, but the shortest name (unless the user specifies otherwise)
is preferred for printing qualified names of symbols in the package.
< Well, you want to treat these all as names for the package, of which
some are slightly more equal than others. I prefer to think of this as
one real name and a list of nicknames. I'm not wedded to this view, but
your suggestion doesn't look like an improvement to me and the manual IS
supposed to be frozen...>
< On the issue of *** and friends, I really dislike Guy's
interpretation. I agree with Moon that the first value is usually what
you want to get at, and that the /'s are there if you want the other
values. I don't like the idea of * values scrolling out of reach just
because some stupid function returned mroe values than I thought it
would. >
< I think that it is treacherous and confusing for WRITE-CHAR #\RETURN
to do anything other than writing a #\RETURN character to the file.
Seems to me that this is low-level and should be literal. Higher level
things like TERPRI can "do the right thing", but I really want some way
to write a #\RETURN code into a file, even on a system that normally
uses CRLF between lines. >
---------------------------------------------------------------------------
More by SEF:
I've still got a big problem with the #+, #- business. I now realize
that these are fundamentally ill-formed constructs. What you want to do
here, if the condition is not met, is to completely skip over the next
Lisp object as though it were commented out -- no value, no errors, no
side effects. The obvious way to do this is to call READ and then throw
away the result, but Moon points out that this could cause errors which
we want to suppress. Similarly, if we run any character macros,
particularly those defined by users, we could very well get errors or
side effects from the "commented out" stuff. On the other hand, we have
to run some of these macros in order to determine where the next object
ends. The problem is that we have made our reader powerful enough that
we cannot assume that the Lisp doing the reading can properly determine
the boundaries of a Lisp object meant to be read by some other
configuration or implementation. We can't win.
The clean solution would be to flush the idea that #+ and #- read one
Lisp object and say that if the condition fails, everything up to some
trivially-recognized terminator is simply skipped, much in the manner
of #|...|# . Then the systems in question would only have to agree on
this terminator, and neither would have to make guesses about the
other's reader.
It's probably too late to change #+ and #-, but I am not willing to
rewrite our reader to make these losing crocks work on a few extra
cases. I propose that we state that if the condition for #+ and #-
fails, then the next object is read by the implementation using READ
(perhaps requiring to switch to the standard Common Lisp readtable to do
this) and the result is discarded. Period. If you've got a hairier
case that is likely to cause unwanted errors or side effects in some
implementation, you don't use #+ or #-.
What do you use in such cases? Some evil #. form would do it, but I
propose that we make it easy for the user. Suppose that we define #0+
and #0- to read a condition, just like #+ and #-, then to read a string
from the input stream, in the normal Common Lisp syntax. (It is an
error if the next item read is anything but a string.) If the condition
is met, the contents of the string gets passed to READ. If the
condition is not met, the string is discarded.
Thus we get things looking like the following:
(defvar awkward-float #0+SYMOBLICS-3600 "+3L27" #0+PERQ "+3L100205")
Note that I hate the Teco-ish look of #0+, but unfortunately Maclisp
grabbed the good names for its faulty concept and it's probably too late
to switch. I suppose that we could find two unused # characters and use
them instead of + and -. Any nominations?
∂01-Oct-83 1503 RPG More comments on excelsior
∂09-Sep-83 1126 @MIT-MC:Moon%SCRC-TENEX@MIT-MC More comments on excelsior
Received: from MIT-MC by SU-AI with TCP/SMTP; 9 Sep 83 11:25:10 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 9-Sep-83 14:23:16-EDT
Date: Friday, 9 September 1983, 14:26-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: More comments on excelsior
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: moon%SCRC-TENEX@MIT-MC, steele@CMU-CS-C, rpg@SU-AI,
dlw%SCRC-TENEX@MIT-MC, bsg%SCRC-TENEX@MIT-MC
Date: Sat, 3 Sep 1983 00:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
p. 141: the new-nicknames argument to rename-package should be &rest,
not &optional, for uniformity.
< I don't see how this furthers the cause of uniformity. I favor
&optional, though not passionately. >
[I don't see the uniformity either.]
This is the uniformity:
"rename-package takes a package and any number of names (at least one) as
arguments. All the package's current names are discarded and the specified
names are made to be the names of the package. The first name specified
is preferred for output, but all of the names are accepted on input."
Actually in our system the first name is preferred for output when printing
the package object, but the shortest name (unless the user specifies otherwise)
is preferred for printing qualified names of symbols in the package.
< Well, you want to treat these all as names for the package, of which
some are slightly more equal than others. I prefer to think of this as
one real name and a list of nicknames. I'm not wedded to this view, but
your suggestion doesn't look like an improvement to me and the manual IS
supposed to be frozen...>
I was hoping one of the other recipients of this message would answer, and
tell you you're just being stubborn. Oh well, it's only a very minor matter
of tastefulness.
< On the issue of *** and friends, I really dislike Guy's
interpretation. I agree with Moon that the first value is usually what
you want to get at, and that the /'s are there if you want the other
values. I don't like the idea of * values scrolling out of reach just
because some stupid function returned mroe values than I thought it
would. >
Either way is okay with me, but tradition, such as it is, is on the side
of * only being the first value, and if you agree too, let's make it be
that way.
< I think that it is treacherous and confusing for WRITE-CHAR #\RETURN
to do anything other than writing a #\RETURN character to the file.
Seems to me that this is low-level and should be literal. Higher level
things like TERPRI can "do the right thing", but I really want some way
to write a #\RETURN code into a file, even on a system that normally
uses CRLF between lines. >
Well, now, hold on. Things aren't so clear as all that. You are assuming
that Common Lisp uses the ascii character set (in fact, "Teletype ascii",
not some of the other ones going around such as "Unix ascii") and that
the character #\Return is the ascii CR character. Some of us have been
assuming that #\Return stands for whatever the implementation-dependent
end-of-line sequence is, and that portable programs using files open
with :element-type character are shielded from the implementation-dependent
character set. Both points of view have merit, and it seems that we have
only just noticed that we weren't all assuming the same thing.
But things like "seems to me that this is low-level and should be literal"
aren't arguments in favor of one or the other way of arranging the character
set. The real issue is are we, or are we not, attempting to hide the
implementation-dependent character set by having a standard character set.
That is the issue. If we are, then the way you write implementation-dependent
characters into a file (e.g. if you use a system whose end-of-line sequence
is Ascii CR followed by Ascii LF, and you want to write a CR without any
LF after it, perhaps to cause overstriking on a lineprinter) is to open
the file with some element-type other than character. You could use an
element-type of (byte 8) [or 7 or 9 depending on the file system], or there
could be an element-type which is character objects, but representing the
implementation-specific character set, not the standard character set.
If on the other hand, we are not trying to hide the implementation-dependent
character set, then the manual must contain a list of standard and semi-standard
characters which, although standard, have implementation-dependent semantics,
and must warn you that the semantics of (write-char #\return) is not defined
by Common Lisp, and portable programs must use (terpri) instead. There are
other warnings that go with this, such as the one about strings that cross
line-boundaries (the length and contents are implementation-dependent), and the
one about keyboard input either not reflecting keys typed one-for-one or not
being legal to just copy into a file, depending on the implementation.
We have to decide *now* which we are doing.
I just looked through the Excelsior manual, trying to find a description of
the character set. I couldn't find one. Page 275 (the #\ reader macro)
seems to be the only place that says what the Return character is. The
phrasing is very ambiguous; I can't tell whether it means that #\return is
the same "newline" that is mentioned in connection with print, terpri, and
the ~% format operator.
Does the Spice operating system perpetuate the use of the two character CR-LF
sequence as a line delimiter in files?
---------------------------------------------------------------------------
More by SEF:
I've still got a big problem with the #+, #- business. I now realize
that these are fundamentally ill-formed constructs....
We just had a discussion of various things related to #+ and #- here a
couple of weeks ago, by coincidence. This convinced me that #+ and #-
are only for simple cases and the cases where you really need them, and
trying to hair them up to handle anything else is a mistake.
...I propose that we state that if the condition for #+ and #-
fails, then the next object is read by the implementation using READ
(perhaps requiring to switch to the standard Common Lisp readtable to do
this) and the result is discarded.
Fine. Except incorporate Steele's suggestion that tokens consisting entirely
of constituents (and colons) do not cause errors when read in "ignore mode."
This is not at all difficult to do (it's a total of perhaps 10 lines of code
in our reader, and simply requires a special variable bound to T by #+/#-
and checked at a few places that could signal errors). There is no need to
handle macros inside of #+/#- specially, although certainly if those macros
care to look at that "ignore mode" flag you can let them. But in general
#+/#- can't be made to "work for all cases."
Oh, and definitely do NOT switch readtables when going into "ignore mode".
Just call READ (with the recursive flag).
(I deleted your ``#0+condition string'' proposal from my reply, since I think
it comes under the category of hairing them up.)
∂01-Oct-83 1504 RPG More comments on excelsior
∂11-Sep-83 1930 FAHLMAN@CMU-CS-C.ARPA More comments on excelsior
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Sep 83 19:30:21 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 11 Sep 83 22:03:23-EDT
Date: Sun, 11 Sep 1983 17:56 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC.ARPA>, steele@CMU-CS-C.ARPA
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
fahlman@CMU-CS-C.ARPA
Subject: More comments on excelsior
In-reply-to: Msg of 9 Sep 1983 14:26-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
OK, it seems that Moon and I both agree that the * variables should not
get a spread of all the returned values as Guy suggested, but only the
first values of the recent evaluations.
It also seems that RENAME-PACKAGE can stay the way it is. (I'm not
being stubborn for the sake of stubbornness, but just to preserve the
principle that only the most important changes should go in at this
point, unless the current version is unworkable, the result of some
confusion, or is being seen for the first time.)
Moon is right in observing that there are two coherent ways to handle
the CRLF business. One could assume, as I had assumed, that a character
within Lisp always represents one character in the external world of
files or whatever, and that translation of TERPRI into CR and LF
characters (on systems that use that convention) occurs within the Lisp,
before the call or calls to WRITE-CHAR. This certainly seems simpler to
me, especially if you ever want to random-access into a text file.
However, if #\RETURN is uniformly treated as a single char within Lisp
but is expanded into a two-char sequence externally, that can be made
consistent too. This hides the differences between systems better, but
anomalies arise if either CR or LF is ever seen in an external file
except as part of the CRLF idiom.
I prefer the scheme in which , but I guess I can live with any
scheme that is not overly complex and that is spelled out unambiguously.
If WRITE-CHAR becomes "helpful" we will want to have access to an
unhelpful (and un-portable) lower level that does exactly what you tell
it to, since sometimes you need to send out a real ASCII CR character as
part of an escape sequence or something. But perhaps this should be a
red-pages function anyway, since it's below the portable level. I think
that trying to make all of this strictly portable may be an open-ended
bag of worms, and I hope that we won't get hung up on this issue for too
long.
As far as I know, Spice has not yet settled on a system-wide standard
newline sequence for text files. I think that Hemlock just writes an
ASCII CR between lines, and on input it turns either CR or CRLF into a
line break. I'm not sure whether the non-Lispy Spice software does the
same.
As for #+ and #-, I guess we all agree that these macros read the item
to be discarded just by calling READ with the recursive flag. The
implementation is required to find some way to prevent an error from
being signalled if the token to be discarded consists entirely of
constitutents and colons. #+ and #- should not be used if this simple
paradigm is likely to result in errors or unwanted side effects. My
suggestion for extending #+ and #- is withdrawn.
-- Scott
∂01-Oct-83 1505 RPG * * ** / // ///
∂12-Sep-83 2051 Guy.Steele@CMU-CS-A * * ** / // ///
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 12 Sep 83 20:51:46 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 12 Sep 83 23:41:27 EDT
Date: 12 Sep 83 2349 EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: * * ** / // ///
CC: moon%scrc-tenex@MIT-MC, bsg%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC,
rpg@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 11 Sep 83 16:56-EST"
I have no particular attachment to any scheme for * ** ***.
What I elucidated was what I understood Moon to mean when he said
that the three kinds of variable (+ * /) were relatively independent.
I'm glad I sent out the explicit example, because it looks as though
I misinterpreted what he meant. If everyone wants * and / kept in lock
step, fine.
∂01-Oct-83 1509 RPG 370 Common Lisp
∂26-Sep-83 1414 @MIT-MC:DLW%SCRC-TENEX@MIT-MC 370 Common Lisp
Received: from MIT-MC by SU-AI with TCP/SMTP; 26 Sep 83 14:14:40 PDT
Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Mon 26-Sep-83 16:32:51-EDT
Date: Monday, 26 September 1983, 16:36-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: 370 Common Lisp
To: Fahlman@CMU-CS-C
Cc: rpg@SU-AI, moon%SCRC-TENEX@MIT-MC, Steele@CMU-CS-C
I just got a call from Dave Parker at MIT. He's with something called
the Computation Research Center for Management Information Sciences,
associated with the Sloane School (MIT's business school). He wants to
do a 370 Lisp, had decided to choose Zetalisp as the dialect, and wanted
to know if anyone had already done it. I told him about Common Lisp,
about getting public domain software from CMU, etc, and recommended that
he call you.
I think it should be obvious how useful it would be for us to have an
implementation that runs on the 370!
I don't know anything about this guy, but from the phone call he
basically seems to be an easy-to-deal with person. I hope he turns out
to be a decent implementor. If, when you talk to him, you feel he's
serious, then I think we should cooperate fully and encourage him.
∂01-Oct-83 1509 RPG 370 Common Lisp
∂26-Sep-83 1424 FAHLMAN@CMU-CS-C.ARPA 370 Common Lisp
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 Sep 83 14:24:00 PDT
Delivery-Notice: While sending this message to SU-AI.ARPA, the
CMU-CS-C.ARPA mailer was obliged to send this message in 50-byte
individually Pushed segments because normal TCP stream transmission
timed out. This probably indicates a problem with the receiving TCP
or SMTP server. See your site's software support if you have any questions.
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 26 Sep 83 17:26:12-EDT
Date: Mon, 26 Sep 1983 17:26 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC.ARPA>
Cc: moon%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA, Steele@CMU-CS-C.ARPA
Subject: 370 Common Lisp
In-reply-to: Msg of 26 Sep 1983 16:36-EDT from Daniel L. Weinreb <DLW%SCRC-TENEX at MIT-MC>
Thanks for the warning. If this guy is for real (that is, if the
probability of success is high and the amount of hand-holding he will
need is low) we would of course be willing to make our sources available
to him and help out as time allows. I assume from what you said that
the plan is for this to be widely available as a free or nearly free
system -- ifhe's trying to make it a commercial product, that raises a
different set of issues.
-- Scott
∂01-Oct-83 1509 RPG Speaking of Public Domain Software
∂26-Sep-83 2119 FAHLMAN@CMU-CS-C.ARPA Speaking of Public Domain Software
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 26 Sep 83 21:17:54 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 27 Sep 83 00:20:25-EDT
Date: Tue, 27 Sep 1983 00:20 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: fahlman@CMU-CS-C.ARPA
Subject: Speaking of Public Domain Software
In-reply-to: Msg of 26 Sep 83 1420 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
That's good news. The more you folks can do in the way of maintenance,
extension, and distribution of the public domain code, the happier we
will be. I want to get on with AI work and my troops want to get into
various user-level things like Hemlock and the Lisp-based shell we're
about to start for Spice, plus assorted yellow-pages goodies.
We will want to have several long talks about the state of various parts
of the system and how best to phase the transfer. For example, I'm in
the middle of a compiler rewrite now to get in lexical closures,
keywords, packages, and lots of little things. You definitely won't
want the old compiler. Also, Skef Wholey is in the middle of an effort
to greatly improve the Perq performance by changing the byte-code set
and hacking intensively on the microcode. Any blue-pages effort should
use the new microcode set.
A key question is how much manpower you have available for this, and
when. What fraction of an RPG is available, and who else, if anyone?
I've got some slightly decrepit files that have been orphaned and that
someone could hack right now, if you've got people who are ready to
roll. An even more interesting question is how you're going to run our
code. Do you have any Perqs? A Dec-20 with extended memory (KL
processor)? Vaxen? Right now our stuff runs best on the slow Dec-20
emulator and on the Perq, though the Dec-20 Common Lisp from Rutgers
should be usable soon. I could get you access to the Dec code for the
Vax, I'm sure, but they do funny things to the code at DEC so this
system lags our sources by a month or so.
A thought is that maybe the best way to get into the blue-pages business
would be to port our code to some other system, such as the Sun. Just a
thought. Without ucode, it would take a fair amount of work on the
compiler to get decent performance, but you could always write a system
that just interpets the byte codes as the microcode does on a Perq.
As for commercial arrangements, I'd like to see all of this code made
available to the world as freely as possible. That's how we will
conquer the world. Companies should pay for people's time at consulting
rates and a copying fee for getting a tape, but the code should be free.
Once you try to milk the company a little the lawyers show up, and if
you try to milk them a lot they might decide not to do a Common Lisp
after all. If you folks at Stanford want to charge for the improved
version of the code, I guess we'd like a cut, but if you are willing to
keep it free, we'd prefer that. The only reason I've made it
inconvenient to get at the code is to prevent people from getting things
prematurely.
All of our files are on CMU-CS-C (a Tops-20 system) in subdirectories of
PRVA:<SLISP>. Help yourself. If you need to login, use <SLGUEST>,
password "anthrax". Other people (Symbolics, RMS, Rutgers...) use that
account too, so don't panic if you run into someone else. Interesting
directories are the following:
PRVA:<SLISP.CODE.NEW> Lisp-level code implementing Common Lisp.
PRVA:<SLISP.COMPILER.NEW> The newest version of the old Maclisp-based
compiler.
PRVA:<SLISP.DOCS> Various documents. Note especially SLGUTS and RED.
PRVA:<EDITOR*> Versions of the Hemlock editor.
-- Scott
∂01-Oct-83 1509 RPG Varia
∂27-Sep-83 1750 FAHLMAN@CMU-CS-C.ARPA Varia
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 Sep 83 17:50:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 27 Sep 83 20:53:18-EDT
Date: Tue, 27 Sep 1983 20:53 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Varia
In-reply-to: Msg of 27 Sep 83 1031 PDT from Dick Gabriel <RPG at SU-AI>
Dick,
It all sounds good. Have you hired the Ph.D. level guy yet? Any of
your possibilities for a machine to run on would work. It is unclear to
me how far along Symbolics is on the 3600 CL or how legal it will be.
Any of a Dec-20, a Vax, or a quick and dirty port to the Sun would put
you in business.
Snarf away on the code. Once you're able to run it there, then we can
think about what things you might want to polish. When the time comes
that you are ready to make changes, we'll set up some sort of
version-control scheme to keep everything in sync.
On the manual: an annotated version would be fine, but probably the
right way to do it is to produce a separate document carefuly indexed to
the published manual. That way you avoid having to deal with copyright
issues. Or, I suppose, you could offer the result to Digital Press --
the Implementor's Edition of the Common Lisp Manual. You, Guy and
Digital Press could doubtless work something out.
-- Scott
∂02-Oct-83 1759 RPG &rest args
∂02-Oct-83 1447 @MIT-MC:MOON@SCRC-TENEX &rest args
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Oct 83 14:46:20 PDT
Date: Sunday, 2 October 1983 17:47-EDT
From: MOON at SCRC-TENEX
To: Fahlman at cmuc
cc: Steele at cmuc, RPG at su-ai, dlw at SCRC-TENEX, bsg at SCRC-TENEX
Subject:&rest args
I think I forgot to include in my message of a couple of days ago
the comment that handling &rest args in an efficient and safe way
is worth doing because it involves solving very much the same problems
as handling lexical closures in an efficient and safe way. The
same spectrum of techniques (user-supplied declarations that dynamic extent of
the object is permissible, removal of the offending construct through
compile-time analysis, run-time detection of unsafe use of the
object that would otherwise be stack-allocated, implementation of
extra efficient consing and garbage collection so that heap allocation
may be used, phantom stacks, or giving up and telling the users that
the construct is inefficient and should not be used) applies in
either case.
∂03-Oct-83 0942 RPG Random idea: bringing back lexprs
∂03-Oct-83 0939 @MIT-MC:BSG%SCRC-TENEX@MIT-MC Random idea: bringing back lexprs
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Oct 83 09:38:56 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 3-Oct-83 12:39:31-EDT
Date: Monday, 3 October 1983, 12:35-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: Random idea: bringing back lexprs
To: MOON%SCRC-TENEX@MIT-MC, Fahlman@CMU-CS-C
Cc: dlw%SCRC-TENEX@MIT-MC, rpg@SU-AI, steele@CMU-CS-C
In-reply-to: The message of 1 Oct 83 01:51-EDT from David A. Moon <MOON at SCRC>
Date: Saturday, 1 October 1983, 01:51-EDT
From: David A. Moon <MOON at SCRC>
I see no reason why a non-cdr-coded Lisp would be unable to allocate a
list in a stack. It simply requires that the list take up twice as much
storage, a price they are already willing to pay when allocating in the
heap, where the extra storage use costs you much more than it does in
the stack.
And the garbage collector knowing about structures living in stacks,
which may or may not be alien to someone's implementation.
∂03-Oct-83 1516 RPG Random idea: bringing back lexprs
∂03-Oct-83 1043 FAHLMAN@CMU-CS-C.ARPA Random idea: bringing back lexprs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 3 Oct 83 10:43:40 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Oct 83 13:44:48-EDT
Date: Mon, 3 Oct 1983 13:44 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, MOON%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
steele@CMU-CS-C.ARPA
Subject: Random idea: bringing back lexprs
In-reply-to: Msg of 3 Oct 1983 12:35-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
For some reason I never got Moon's comment about allocating
non-CDR-coded lists in a stack. Sure, you could do this, but you
couldn't just modify the args as they are pushed (unless the caller
arranged to know just which args are going to be restified). You would
have to copy the args into a separate stack or some other place on the
control stack. And, as BSG points out, this can cause substantial pain
for the GC in many implementations. All this hair is to provide the user
with the fiction of a list when what he really wants (usually, not
always) is to be able to iterate over an indefinite set of args.
Aside from compatibility, I guess I don't see why it is tasteful to
require the user to declare whether the list is to be real-but-slow or
fast-but-downward-only, but it is not OK to require him to say (by his
choice of &REST vs &MORE) whether he really wants a list or not? Why
mess with the dangerous concept of volatile lists when the problem is
easily solved by not making a list at all if you don't need a real one?
I don't really buy Moon's argument that the exercise will do us good,
because there are other things that want to special cased if used
downwards-only. Why hassle the user with one more tricky concept?
Oh, well, I seem to be losing this argument. Guess I'll shelve the idea
until the night before flag day for the second edition and see if I can
zip it past people when they are all busy fighting about Flavors vs.
Smells or whatever. In the meantime we'll just continue to cons up
&rest args for no good reason. As I said, it was just a random
late-night idea.
-- Scott
∂03-Oct-83 1517 RPG Random idea: bringing back lexprs
∂03-Oct-83 1456 @MIT-MC:MOON@SCRC-TENEX Random idea: bringing back lexprs
Received: from MIT-MC by SU-AI with TCP/SMTP; 3 Oct 83 14:56:06 PDT
Date: Monday, 3 October 1983 14:12-EDT
From: MOON at SCRC-TENEX
To: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Cc: Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC.ARPA>,
dlw%SCRC-TENEX at MIT-MC.ARPA, MOON%SCRC-TENEX at MIT-MC.ARPA,
rpg at SU-AI.ARPA, steele at CMU-CS-C.ARPA
Subject: Random idea: bringing back lexprs
In-reply-to: The message of Mon 3 Oct 1983 13:44 EDT from Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
It sounds like you also never saw my message saying that &MORE was
an okay idea and would be all right to add to the language, even
though I think that the majority of functions that take &REST
arguments will not be able to switch to it.
---
The effing .ARPA's did their best to prevent you from seeing this
message. I don't think that's why you didn't see my previous message,
since this time the mailer told me that it couldn't deliver the
message because the host names were bogus..
∂03-Oct-83 1601 RPG Random idea: bringing back lexprs
∂03-Oct-83 1531 FAHLMAN@CMU-CS-C.ARPA Random idea: bringing back lexprs
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 3 Oct 83 15:31:37 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Oct 83 18:32:57-EDT
Date: Mon, 3 Oct 1983 18:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: MOON%SCRC-TENEX@MIT-MC.ARPA
Cc: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC.ARPA>,
dlw%SCRC-TENEX@MIT-MC.ARPA, MOON%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
steele@CMU-CS-C.ARPA
Subject: Random idea: bringing back lexprs
In-reply-to: Msg of 3 Oct 1983 14:12-EDT from MOON at SCRC-TENEX
Dave,
Indeed, I seem to have missed a few of your messages and only seem to
have seen the negative ones. In any event, having added the message to
the queue for some future discussion and having kicked around some of
the issues, we should probably let it rest for now and the resurrect the
discussion on the full Common-Lisp list a few months hence. We've all
got enough to do in the meantime, I imagine.
-- Scott
∂05-Oct-83 2020 @MIT-ML:ALAN@MIT-MC No No! Flush it!!
Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Oct 83 20:20:15 PDT
Date: 5 October 1983 23:11 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: No No! Flush it!!
To: Common-Lisp @ SU-AI
It is a Common Lisp philosophy that we shold flush any storing functions
where a SETF of an accessor will suffice. Well I suggest that we flush
PUSH for this reason. Instead of (PUSH X (CAR Y)) programmers should be
encouraged to write (SETF (POP (CAR Y)) X)!
∂05-Oct-83 2044 HEDRICK@RUTGERS.ARPA Re: No No! Flush it!!
Received: from RUTGERS by SU-AI with TCP/SMTP; 5 Oct 83 20:44:11 PDT
Date: 5 Oct 83 23:45:46 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: No No! Flush it!!
To: ALAN%MIT-MC@MIT-ML.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: Message from "Alan Bawden <ALAN @ MIT-MC>" of 5 Oct 83 23:11:00 EDT
One of the reasons that I am suspicious about Common Lisp's design is
that I can never be sure when people are serious and when they are
spoofing me. I would like to think that the idea of turning PUSH
into (SETF (POP was a joke. But there is enough doubt that I am going
to answer it as if it were serious.
I think of SETF as being used to put values into "fields" of data
structures. I am prepared to think of (CAR X) as being a field, and
I can even imagine (GET X Y) as one, though I think that is pushing
it. (Certainly our Common Lisp will have PUTPROP.) But PUSH
simply pushes me beyond my ability to think in those terms. Among
other things, it has sideeffects. And (SETF (POP suggests the
wrong sideeffects, unless you think hard.
Please tell me you weren't serious.
-------
∂05-Oct-83 2052 FAHLMAN@CMU-CS-C.ARPA No No! Flush it!!
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Oct 83 20:52:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Oct 83 23:53:55-EDT
Date: Wed, 5 Oct 1983 23:53 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: No No! Flush it!!
In-reply-to: Msg of 5 Oct 1983 23:11 EDT from Alan Bawden <ALAN at MIT-MC>
Bawden is misinformed. Common Lisp has no philosophy. We are held
together only by a shared disgust for all the alternatives.
-- Scott
∂05-Oct-83 2112 GSB@MIT-ML No No! Flush it!!
Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Oct 83 21:12:38 PDT
Date: 6 October 1983 00:06 EDT
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: No No! Flush it!!
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI, ALAN @ MIT-MC
Ahh, but if we use (setf (pop ...) ...) then we don't have to commit
ourselves to the order of arguments to PUS, because we don't have one.
p.s. When alan and i were talking about this, Carrette walked into
the room and asked what kind of drugs were in the tea. I don't think
Alan knows if he is serious.
∂05-Oct-83 2229 @MIT-ML:ALAN@MIT-MC No No! Flush it!!
Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Oct 83 22:29:07 PDT
Date: 6 October 1983 01:28 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: No No! Flush it!!
To: HEDRICK @ RUTGERS
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of 5 Oct 83 23:45:46 EDT from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
I wasn't sure whether I was kidding or not originally. I took a poll of
those Lisp programmers who just happened to be here in the building, and
recieved the mixed reviews you might expect. (Everything from "I like it!
I like it!" to "You're crazy Bawden, it's a total loss", about evenly
split.)
I think I am now convinced that the idea could fly. BUT... I took a close
look at the SETF method protocol documented on page 80 of the manual, and I
believe that the mechanism is not powerful enought to cover a case like
this one. It says:
"The value returned by the accessing form is (of course) affected by
execution of the storing form, but otherwise either of these forms may
be evaluated any number of times, and therefore should be free of side
effects (other than the storing action of the storing form)."
All implementations that I have seen of this so far, including my own
original one, have the property that they depend on this clause of the
contract of a SETF method. I don't see how to implement SETF of POP
without violating this clause. I DO think that I could redesign this stuff
to handle this case, but I DON'T think Common Lisp should consider this
extension at this time.
You can all relax now.
∂05-Oct-83 2252 FAHLMAN@CMU-CS-C.ARPA No No! Flush it!!
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Oct 83 22:52:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Oct 83 01:53:56-EDT
Date: Thu, 6 Oct 1983 01:53 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: No No! Flush it!!
In-reply-to: Msg of 6 Oct 1983 01:28 EDT from Alan Bawden <ALAN at MIT-MC>
(-:
Gee, and while we're at it we can flush things like (setq x (sqrt 2))
and just go for (setf (* x x) 2). Now if I can figure out how to do
matrix inversion by feeding this thing multiple values...
:-)
∂05-Oct-83 2351 Guy.Steele@CMU-CS-A You thought you were kidding
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 5 Oct 83 23:51:21 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 6 Oct 83 02:39:54 EDT
Date: 6 Oct 83 0248 EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: Scott E. Fahlman <Fahlman@CMU-CS-C>
Subject: You thought you were kidding
CC: common-lisp@SU-AI
In-Reply-To: "Scott E. Fahlman's message of 6 Oct 83 00:53-EST"
)-: Well, maybe we can't use setf to get sqrt, but:
(defsetf * (x &rest y) (newval)
`(progn (setf ,x (/ ,newval ,@y)) ,newval))
(setf (* x 4) 24) => 24
and now x => 6
I just tried this in VAX Common LISP. It works fine.
--Guy
∂06-Oct-83 0013 FAHLMAN@CMU-CS-C.ARPA You thought you were kidding
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Oct 83 00:13:38 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 6 Oct 83 03:15:34-EDT
Date: Thu, 6 Oct 1983 03:15 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: You thought you were kidding
In-reply-to: Msg of 6 Oct 83 0248 EDT () from Guy.Steele at CMU-CS-A
Well, now I know how the Sorcerer's Apprentice felt when the brooms
started schlepping water. (Or was that Mickey Mouse?) Please, nobody
make any jokes about how to use SETF to launch the nuclear missiles --
Guy will try it and it will work. This is scary.
∂06-Oct-83 0126 Guy.Steele@CMU-CS-A Really kidding, now
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 6 Oct 83 01:26:31 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 6 Oct 83 04:17:46 EDT
Date: 6 Oct 83 0426 EDT (Thursday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Really kidding, now
(defsetf logand (x y) (newval)
`(if (= (logand y newval) newval)
(progn (setf ,x (logior newval
(logand (random (expt 2 (max (integer-length
,newval)
(integer-length
,y))))
(lognot y))))
,newval)
(error "Impossible setf.")))
So then when you say
(setf (logand x 12) 8)
x will get set to some random value such that when it is anded with
12 you will get 8. (X might get set to 9 or 10, for example.)
--Guy
∂06-Oct-83 0432 NEDVED@CMU-CS-C.ARPA please route
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Oct 83 04:32:38 PDT
Delivery-Notice: While sending this message to SU-AI.ARPA, the
CMU-CS-C.ARPA mailer was obliged to send this message in 50-byte
individually Pushed segments because normal TCP stream transmission
timed out. This probably indicates a problem with the receiving TCP
or SMTP server. See your site's software support if you have any questions.
Received: ID <NEDVED@CMU-CS-C.ARPA>; Thu 6 Oct 83 07:33:44-EDT
Date: Thu 6 Oct 83 07:33:44-EDT
From: Nedved@CMU-CS-C.ARPA
Subject: please route
To: Common-Lisp@SU-AI.ARPA
Sigh. No "-Request" to send changes to without cluttering people's
mail boxes.
---------------
Date: Thu 6 Oct 83 02:21:54-EDT
From: The Mailer Daemon <Mailer@CMU-CS-C.ARPA>
To: NEDVED@CMU-CS-C.ARPA
Subject: Message of 6-Oct-83 02:21:04
Message failed for the following:
Common-Lisp-Request@SU-AI.ARPA: 550 I don't know anybody named Common-Lisp-Request
------------
Received: ID <NEDVED@CMU-CS-C.ARPA>; Thu 6 Oct 83 02:21:05-EDT
Date: Thu 6 Oct 83 02:21:04-EDT
From: Nedved@CMU-CS-C.ARPA
Subject: please route
To: Common-Lisp-Request@SU-AI.ARPA
cc: Feinberg@CMU-CS-C.ARPA
Please change Feinberg@CMU-CS-C to Feinberg%scrc-vixen@MIT-MC. Thanks!
-Rudy
A CMU Postmaster
-------
-------
-------
∂07-Oct-83 0101 Guy.Steele@CMU-CS-A SETF madness :-)
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 7 Oct 83 01:01:15 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 7 Oct 83 03:51:28 EDT
Date: 7 Oct 83 0400 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: SETF madness :-)
Who needs UNREAD-CHAR? Just (SETF (READ-CHAR stream) char) and
then (READ-CHAR stream) will return the char.
Who needs RENAME-FILE? Just (SETF (TRUENAME stream) newname) ...
Who needs DELETE-FILE? Just (MAKUNBOUND (TRUENAME stream)) ...
(Clearly we need MAKUNBOUNDF.)
And, of course, if you need to make the sun stand still for a while,
you do (LET ((NOW (GET-UNIVERSAL-TIME)))
(LOOP (SETF (GET-UNIVERSAL-TIME) NOW)))
until you hit ↑G.
Who needs CHAR-UPCASE? Just put the character into the variable X,
and then do (SETF (UPPER-CASE-P X) T). Presto change-o!
What some implementations call KWOTE [ (DEFUN KWOTE (X) (LIST 'QUOTE X)) ]
can be done as (SETF (EVAL X) Y) <=> (SETQ X (KWOTE Y)).
Finally, who needs PARSE-INTEGER??? If X is a string, and you want to
know what it means as an octal integer, just say
(SETF (FORMAT NIL "~O" VAL) X)
Simple, eh?
--Quux
∂07-Oct-83 1531 @MIT-XX:BENSON@SPA-NIMBUS SETF madness :-)
Received: from MIT-XX by SU-AI with TCP/SMTP; 7 Oct 83 15:31:24 PDT
Received: from SPA-RUSSIAN by SPA-Nimbus with CHAOS; Fri 7-Oct-83 15:29:53-PDT
Date: Friday, 7 October 1983, 15:29-PDT
From: Eric Benson <BENSON at SPA-Nimbus>
Subject: SETF madness :-)
To: Guy.Steele at CMU-CS-A, common-lisp at SU-AI
In-reply-to: The message of 7 Oct 83 01:00-PDT from Guy.Steele at CMU-CS-A
Date: 7 Oct 83 0400 EDT (Friday)
From: Guy.Steele@CMU-CS-A
Who needs DELETE-FILE? Just (MAKUNBOUND (TRUENAME stream)) ...
(Clearly we need MAKUNBOUNDF.)
No, we don't need MAKUNBOUNDF. Just make a small change in the
definition of multiple values so that storing zero values is the same as
making something unbound. Thus
(MAKUNBOUND 'FOO) becomes (SETF (SYMBOL-VALUE 'FOO) (VALUES))
(FMAKUNBOUND 'FOO) becomes (SETF (SYMBOL-FUNCTION 'FOO) (VALUES))
(REMPROP 'FOO 'BAR) becomes (SETF (GET 'FOO 'BAR) (VALUES))
And another thing, why are multiple values restricted to come in
non-negative integral quantities? We shouldn't unduly restrict users
who may desire fractional, negative or complex numbers of values.
Why is RANDOM restricted to numbers? I think it should be defined to
return an arbitrary Lisp object at random. (For those of you with
3600s, try (%MAKE-POINTER (RANDOM 63.) (RANDOM (↑ 2 28.))). Don't do it
if you have any active buffers, though.)
∂08-Oct-83 0728 WVANROGGEN@DEC-MARLBORO.ARPA SETF madness
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 8 Oct 83 07:28:42 PDT
Date: Sat 8 Oct 83 10:29:44-EDT
From: WVANROGGEN@DEC-MARLBORO.ARPA
Subject: SETF madness
To: Guy.Steele@CMU-CS-A.ARPA
cc: common-lisp@SU-AI.ARPA
This is going a bit too far. I can put up with a lot of the cute
features Common Lisp has, but these last suggestions are just going to
be too difficult to implement (at least on a Vax). I'd strongly
recommend *against* these changes to the Excelsior edition.
Instead, we ought to consider what users would really want. If Common
Lisp is supposed to be a general, common language usable by everyone,
we should provide something like:
(setf (eval `(let* ((pretime (get-internal-real-time))
(precond <<pre-condition>>))
,@x
(and precond
<<post-condition>>
(< pretime (+ (get-internal-real-time) <<time-limit>>)))))
t)
for user-supplied <<pre-condition>>, <<post-condition>>, and <<time-limit>>.
Implementors should be encouraged to design SETF so that it also meets
these conditions (of course).
---Walter
-------
∂10-Oct-83 2320 RPG Nasty issues for Common LISP Manual
∂06-Oct-83 2312 STEELE@CMU-CS-C.ARPA Nasty issues for Common LISP Manual
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Oct 83 23:11:47 PDT
Received: ID <STEELE@CMU-CS-C.ARPA>; Fri 7 Oct 83 02:14:58-EDT
Date: Fri 7 Oct 83 02:14:54-EDT
From: STEELE@CMU-CS-C.ARPA
Subject: Nasty issues for Common LISP Manual
To: fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, moon%scrc-tenex@MIT-ML.ARPA,
dlw%scrc-tenex@MIT-ML.ARPA
In going over all the comments of the last several months, attempting to
get the manual wrapped up, I have encountered some Very Hard Issues that
I have been avoiding until I had reread all the mail. The time has come.
For each of the issues below, I review the problem and recommend a
solution that I will use unless I get a lot of flak real soon.
I solicit your advice on all of these issues.
I have committed to sending a "final draft" to Digital press by Tuesday;
it is from this copy that we will begin doing the SCRIBE design for the
phototypesetter. This "final draft" need not contain the final solutions
to all these problems, but it would be nice to get in as many as
possible, so I beg for quick turnaround. It sure would be nice to get
this whole thing off my back well before Thanksgiving.
--Guy
(1) The lexical scope of MACROLET macros. The scope of the defined
names is clearly lexical; there is no problem there. But what is
visible to the *bodies* of the macros defined in a MACROLET?
Lexical scope doesn't work, because the values don't exist at
macro-expansion time in a compiler, for example.
(defun foo (x z)
(macrolet ((weirdp (y) `(or (numberp ,y) (eql ,y ,x))))
(if (weirdp z) ...)))
The compiler has no hope of producing a correct expansion of weirdp
if the reference to x is taken to be to the parameter of foo.
(Note that there would be no difficulty if "x" had appeared in place
of ",x"; but that would mean a different thing.)
Proposed solution: the bodies of macro-definition functions for
macros defined by macrolet are closed in the global environment,
not in the current lexical environment.
(2) How shall tokens be parsed? The introduction of package syntax has
made this very complicated. It is almost impossible to provide a
coherent explanation of how vertical bars work if vertical bar remains a
macro character. There are also questions of what such tokens as 123:foo
and foo:123 mean. This is not so much an implementation problem as a
documentation problem, but the fact that the explanation has to be
contorted indicates that something is wrong.
Proposed solution: introduce a fifth kind of character (in addition to
constituent, escape, whitespace, and macro character), called a multiple
escape character, the old kind of escape being called a single escape
character. Change the rules for reading a token so that when a
multiple-escape character is seen, either initially or in the middle of a
token, then all following whitespace, constituent, and macro characters
are treated as alphabetic constituents; any single escape character
causes the next character to be treated as a constituent; and any
multiple escape character causes you to revert to the mode of
accumulating until a whitespace or terminating macro character is seen.
Put more simply, a vertical bar toggles whether you are in vertical-bar
mode, but never terminates the token in and of itself.
This has the consequence that |foo|bar|baz| is a single token that will
be interpreted as a symbol with print name "fooBARbaz", rather than being
three distinct symbols. It also has the more desirable consequence that
|foo|:|bar| naturally gets treated as a single token.
The rule is then: scan over a single token. Then the characters must
fall into one of the following patterns:
number-syntax a number
no-package-markers a symbol
:xxxxx a keyword
xxxxx:yyyyy a symbol yyyyy in package xxxxx
xxxxx#:yyyyy an internal symbol yyyyy in package xxxxx
It "is an error" for xxxxx or yyyyy to have the syntax of a number.
It "is an error" for there to be any other pattern of package markers
(therefore an implementation can define what xxxxx: or xxx:yyy:zzz means).
(3) What shall the infix internal package syntax be? Currently it
is "#:". If the proposed solution to problem (2) above is implemented,
then thee is no remaining problem with having to look ahead two characters
after a vertical bar; given that # is a non-terminating macro character,
|foo|#:bar will naturally be read as a single token with no difficulty.
But there remain a few smaller difficulties. One is explaining that
infix #: syntax has nothing whatsoever to do with the use of "#" as
a macro character, and indeed depends heavily on that particular use
of "#" *not* being interpreted as a macro character. Another is the
confusion of the "#|" reader macro when it encounters "|#" within
|foo|#:|bar|. A third, primarily aesthetic, is simply avoiding making
any more characters "magic" in the syntax of tokens than is necessary;
it would be nice to avoid wiring "#" into the syntax of symbols.
Proposed solution: use "::" instead of "#:" for internal package references.
(4) End-of-file and the recursive-p argument. It has been pointed out
that if the recursive-p argument is true and you hit end-of-file, then
you must be in the middle of reading an object, and therefore it is in
order always to signal an error, regardless of the value of eof-errorp of
the top-level call. (However, having the recursive-p argument be true
differs from having eof-errorp be true, because recursive-p also controls
whitespace preservation and the scoping of #n=. Also, the method of
error handling may be interested in being able to locate the top-level
call.)
Proposed solution: adopt this interpretation of recursive-p, changing the
definition on page 290.
(5) How shall #+ and #- operate? In current implementations there is
typically the problem that a strange kind of number or a symbol that
refers to a non-existent package will not be skipped properly even when
conditionalized out by #+ or #-.
Proposed solution: define #+ and #-, when skipping, to perform a READ
operation and then return zero values. All the normal operations of
reading are carried out, including invocation of macro characters,
with the following exceptions:
(a) all tokens are completely uninterpreted and are treated as being NIL;
that is, when a token is scanned, its characters are discarded and
NIL is returned as its value. (This stipulation is important because
user-defined macro characters may read something following, and you have
to say what they see.)
(b) #\ will not complain about reading the name of an unknown character.
(c) #*, #B, #O, #X, #nR will swallow a following token but not complain
about its syntax.
An optional sub-proposal, which I will *not* put in, despite the fact
that I favor it, unless you all agree it is a very good thing, is to make
this machinery accessible to the user: stipulate that the function read
takes one more optional argument called suppress-p, and that
macro-character functions receive suppress-p as an additional argument
(this is how #\ can decide whether or not to complain).
(6) Must the compiler preserve the eql-ness of constants defined
by defconstant?
Proposed solution: Yes. The compiler may perform substitutions of
constants only when it can guarantee preservation of the semantics
of defconstant as a global variable whose value is fixed.
(7) Must there be a new data type lexical-closure?
Proposed solution: No. Let "closure" be a "conceptual data type",
like a-list. The predicate "functionp" must be true of a closure,
just as it must be true of a symbol or of a list whose car is LAMBDA
(these elicidations need to be added to the description of functionp,
by the way). A closure may be implemented as a list whose car is
CLOSURE, for example, or perhaps more tastefully as a structure.
A closure for compiled code might have a type that is a subtype of
COMPILED-FUNCTION, but need not.
(8) The functions READ-BINARY-OBJECT and WRITE-BINARY-OBJECT are
so general that they are giving implementors fits.
Proposed solution: flush them. Individual implementors may choose
to demote them to the red pages, possibly supporting only restricted
cases. For portable purposes there are READ-BYTE and WRITE-BYTE.
Leave any other binary I/O for the second edition.
(9) There are arguments to the effect that a single pathname in
*load-pathname-defaults* cannot possibly interact correctly with
both LOAD and COMPILE-FILE. The argument essentially centers
on the use of non-standard file types. There have been other
complaints about this defaulting mechanism as being too restrictive
or culturally incompatible with certain host environments.
Proposed solution: flush the variables *load-pathname-defaults*,
*compile-file-set-default-pathname*, and *load-set-default-pathname*.
Flush the :set-default-pathname argument to both load and compile-file.
Make the first argument to both load and compile-file be required, not
optional.
(10) There is a functional hole in the language in that there is
no good way to copy a structure. One implementor has proposed that
a function COPY-STRUCTURE is needed. This is not necessarily a
good idea, particularly since there is no STRUCTURE type specifier.
One could also just invent a general COPY function. This has problems,
too.
Proposed solution: let there be a new defstruct option, :COPIER,
analogous to :PREDICATE and :CONSTRUCTOR. If omitted, you get
a simple copying function that is more or less equivalent to
extracting all the fields from the given structure and feeding
their values to the standard constructor. The advantage of this
is that if a structure has complicated internal invariants (such
as not sharing certain substructure with other instances of the
structure) then the copier, like the constructor, can maintain
these invariants. Question: is this (a per-structure-type copy
function) sufficient for people's needs?
(11) Should read-delimited-list modify the readtable?
As currently documented, read-delimited-list does *not* modify
the readtable entry for the delimiter character; it is suggested
that this is the responsibility of the user of read-delimited-list.
Others have suggested that read-delimited-list itself should
temporarily, under an unwind-protect, make the delimiter character
have macro syntax equivalent to, say, ")".
Proposed solution: leave it as is, and put in a stronger warning
about setting it up yourself.
(12) There have been complaints that letting ~T output two spaces
when the column cannot be determined is relatively useless.
It has been suggested that the behavior for strings be adopted
in all cases where the absolute column cannot be determined:
assume that one is at column zero as of the beginning of the
format operation, and format can keep track of things from there.
Proposed solution: adopt this idea. Put in a note that code will be
portable among more devices if all format strings actually do begin at
column zero or start out with ~% or ~&.
(13) What should enough-namestring really do? It has been pointed out
that if the first argument to enough-namestring is a partially-specified
pathname (missing components) then it cannot possibly obey the given
definition in general.
Proposed solution: change the requirement to:
(merge-pathnames (enough-namestring <pathname> <defaults>) <defaults>)
<=> (merge-pathnames <pathname> <defaults>)
I think this is what I originally meant, but muddled it up. Will this work?
(14) Are (terpri) and (write-char #\Return) the same or different?
And what of (format t "~%")? How many characters are in the string "
" ?
Proposed solution: It is imperative that Common LISP shield the
user from character-set problems for ordinary textual cases, even at
the cost of some mapping. Define (terpri) and (write-char #\Return)
to be identical in behavior. Note that (write-char #\Linefeed)
is implementation-dependent; in particular, it is permissible for
an implementation to make (write-line #\Linefeed) emit an ASCII ↑J
unless it immediately follows a (write-line #\Return) for which
the sequence ↑M ↑J was emitted. (This is what MacLISP does.)
This has repercussions on the definition of filepos on text files.
The string "
" may be of length 1 or 2, depending on whether CRLF sequences are
mapped to simply #\Return or not in that implementation. However,
printing such a string will always produce the effect of a single
end-of-line operation.
Note that the internal encoding of #\Return need not be as the ASCII
↑M; indeed, it might well be ↑J! (We should have called it #\Newline,
except for the fact that #\Return reminds people so nicely of the
Return key on most keyboards.)
All this applies only to files opened with :element-type string-char
or character.
(15) What are the precise semantics of eval-when?
Proposed solution: This is what is used in Spice LISP.
When EVAL sees an EVAL-WHEN form, it looks for the word EVAL,
and evaluates the forms in the body. That's all there is to it.
When the compiler processes a file, it first binds two flag variables:
E-W-LOAD to true and E-W-COMPILE to false. It then processes each
form in the file.
The compiler processes a form as follows. First, if E-W-COMPILE is true,
then give the form to EVAL and discard the result. Next, if E-W-LOAD is
true, then there are several cases. If the form is an EVAL-WHEN, then
rebind the two flag variables, each one being true iff its corresponding
word is present in the EVAL-WHEN form, and recursively process the forms
contained; the flag variables are unbound when the recursive processing
of the EVAL-WHEN ends. If E-W-LOAD is true and the form is one of
several things, such as DEFUN, then code is compiled. Certain actions
are taken for some forms regardless of the state of E-W-LOAD, such
as recognizing macros defined by DEFMACRO for compilation purposes.
The compiler may choose to apply MACROEXPAND or MACROEXPAND-1 to
a form at any time in order to determine what kind of form it is,
and it must do so before deciding that a form is not of a certain
kind (such as EVAL-WHEN or DEFMACRO).
This model has several interesting consequences. One is that when
EVAL-WHEN forms are nested, the successive values of E-W-COMPILE may
oscillate, but once E-W-LOAD becomes false no more nested EVAl-WHEN forms
are processed (in the sense of rebinding the flag variables, although
they will be evaluated, and thus subject to the EVAL word, if E-W-COMPILE
is true).
Consider this example:
(eval-when (compile load)
(eval-when (compile eval)
(setq x (+ x 1))))
The variable x will be incremented *twice* at compile time!
It gets incremented once because the inner EVAL-WHEN form is given
to EVAL at the direction of the outer EVAL-WHEN form; EVAL then evaluates
the SETQ because it sees EVAL there. It gets incremented again because
the outer EVAL-WHEN form, which contains LOAD, directs that the inner
EVAL-WHEN form be "processed", and because the inner EVAL-WHEN contains
COMPILE, the SETQ will be evaluated at compile time at the direction of
the inner EVAL-WHEN.
Question: is this model consistent with what LISP Machine LISP does now?
If not, why not? Is this an acceptable model?
-------
∂10-Oct-83 2320 RPG [STEELE: Nasty issues for Common LISP Manual]
∂07-Oct-83 1005 FAHLMAN@CMU-CS-C.ARPA [STEELE: Nasty issues for Common LISP Manual]
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 7 Oct 83 10:04:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 7 Oct 83 13:07:38-EDT
Date: Fri, 7 Oct 1983 13:07 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, moon%SCRC-TENEX@MIT-ML.ARPA,
dlw%SCRC-TENEX@MIT-ML.ARPA, fahlman@CMU-CS-C.ARPA
Subject: [STEELE: Nasty issues for Common LISP Manual]
< My comments in pointy brackets -- SEF >
(1) The lexical scope of MACROLET macros.
Proposed solution: the bodies of macro-definition functions for
macros defined by macrolet are closed in the global environment,
not in the current lexical environment.
< Actually, given all this scoping hair, I would favor flushing
MACROLET. It is confusing as hell and not very useful. Does anyone
have an important use for this facility? However, I would be willing to
live with the solution above. >
(2) How shall tokens be parsed?
Proposed solution: introduce a fifth kind of character (in addition to
constituent, escape, whitespace, and macro character), called a multiple
escape character, the old kind of escape being called a single escape
character. Change the rules for reading a token so that when a
multiple-escape character is seen, either initially or in the middle of a
token, then all following whitespace, constituent, and macro characters
are treated as alphabetic constituents; any single escape character
causes the next character to be treated as a constituent; and any
multiple escape character causes you to revert to the mode of
accumulating until a whitespace or terminating macro character is seen.
Put more simply, a vertical bar toggles whether you are in vertical-bar
mode, but never terminates the token in and of itself.
It "is an error" for xxxxx or yyyyy to have the syntax of a number.
It "is an error" for there to be any other pattern of package markers
(therefore an implementation can define what xxxxx: or xxx:yyy:zzz means).
< I like this solution. It is painful to add another magic character
type, but this makes everything much simpler and clearer than plans that
tried to handle || as a macro. >
(3) Proposed solution: use "::" instead of "#:" for internal package
references.
< I have discussed this at some length with Guy, and strongly favor the
change to "::". Again, we are avoiding a lot of conceptual hair by
doing this. >
(4) End-of-file and the recursive-p argument. It has been pointed out
that if the recursive-p argument is true and you hit end-of-file, then
you must be in the middle of reading an object, and therefore it is in
order always to signal an error, regardless of the value of eof-errorp of
the top-level call. (However, having the recursive-p argument be true
differs from having eof-errorp be true, because recursive-p also controls
whitespace preservation and the scoping of #n=. Also, the method of
error handling may be interested in being able to locate the top-level
call.)
Proposed solution: adopt this interpretation of recursive-p, changing the
definition on page 290.
< Actually, I think one more epicycle is needed: EOF should be
considered as a terminating character followed by the end of file. If a
terminator would cause the recursive call to exit normally, it does
that, and the EOF problem is worried about by the caller. If you're
down in a recursive-p call in a situation where the terminator would not
exit normally, that's when you ALWAYS signal the error. >
(5) How shall #+ and #- operate?
Proposed solution: define #+ and #-, when skipping, to perform a READ
operation and then return zero values. All the normal operations of
reading are carried out, including invocation of macro characters,
with the following exceptions:
(a) all tokens are completely uninterpreted and are treated as being NIL;
that is, when a token is scanned, its characters are discarded and
NIL is returned as its value. (This stipulation is important because
user-defined macro characters may read something following, and you have
to say what they see.)
(b) #\ will not complain about reading the name of an unknown character.
(c) #*, #B, #O, #X, #nR will swallow a following token but not complain
about its syntax.
< This proposal sounds like the lesser of evils to me. I'd go with it.>
An optional sub-proposal, which I will *not* put in, despite the fact
that I favor it, unless you all agree it is a very good thing, is to make
this machinery accessible to the user: stipulate that the function read
takes one more optional argument called suppress-p, and that
macro-character functions receive suppress-p as an additional argument
(this is how #\ can decide whether or not to complain).
< We will obviously have something like this inside, but rather than
hair up the language any further in this area, I'd send in suppress-p
via a special and not tell the user about it. I wouldn't object to
treating it as an argument, however, if other people think the user
wants to get at this. >
(6) Must the compiler preserve the eql-ness of constants defined
by defconstant?
Proposed solution: Yes. The compiler may perform substitutions of
constants only when it can guarantee preservation of the semantics
of defconstant as a global variable whose value is fixed.
< I agree with this. >
(7) Must there be a new data type lexical-closure?
Proposed solution: No. Let "closure" be a "conceptual data type",
like a-list. The predicate "functionp" must be true of a closure,
just as it must be true of a symbol or of a list whose car is LAMBDA
(these elicidations need to be added to the description of functionp,
by the way). A closure may be implemented as a list whose car is
CLOSURE, for example, or perhaps more tastefully as a structure.
A closure for compiled code might have a type that is a subtype of
COMPILED-FUNCTION, but need not.
< No objection. On the other hand, I wouldn't object to a real
data-type either. A careful pass is needed to make the manual
self-consistent in this area in any event. >
(8) The functions READ-BINARY-OBJECT and WRITE-BINARY-OBJECT are
so general that they are giving implementors fits.
Proposed solution: flush them.
< Yes!!! We will implement some parts of this facility as
implementation-dependent calls usable by FASLOAD and friends. For
example, we want to be able to quickly dump a bignum or vector of
numbers into a binary stream of 8-bit bytes. But having to be able to
read and dump ALL of these data types from ALL kinds of binary streams
creates a huge case analysis task, only a few of whose branches are
useful. Leave stuff on this level to the implementor's discretion. >
(9) Proposed solution: flush the variables *load-pathname-defaults*,
*compile-file-set-default-pathname*, and *load-set-default-pathname*.
Flush the :set-default-pathname argument to both load and compile-file.
Make the first argument to both load and compile-file be required, not
optional.
< I am strongly in favor of this. The slight added convenience of being
able to just say (LOAD) is not worth the added conceptual hair of all
this defaulting. Plus, the current scheme has some bugs and people who
have not used ITS will find the sticky-name convention confusing. It's
easy enough to define a COMPILE-AND-LOAD or RELOAD option locally, if
that's what people want. >
(10) There is a functional hole in the language in that there is
no good way to copy a structure. One implementor has proposed that
a function COPY-STRUCTURE is needed. This is not necessarily a
good idea, particularly since there is no STRUCTURE type specifier.
One could also just invent a general COPY function. This has problems,
too.
Proposed solution: let there be a new defstruct option, :COPIER,
analogous to :PREDICATE and :CONSTRUCTOR. If omitted, you get
a simple copying function that is more or less equivalent to
extracting all the fields from the given structure and feeding
their values to the standard constructor. The advantage of this
is that if a structure has complicated internal invariants (such
as not sharing certain substructure with other instances of the
structure) then the copier, like the constructor, can maintain
these invariants. Question: is this (a per-structure-type copy
function) sufficient for people's needs?
< Hirsute, but workable. Why is a universal COPY function (top-level
structure only in structured objects) not workable? >
(11) Should read-delimited-list modify the readtable?
As currently documented, read-delimited-list does *not* modify
the readtable entry for the delimiter character; it is suggested
that this is the responsibility of the user of read-delimited-list.
Others have suggested that read-delimited-list itself should
temporarily, under an unwind-protect, make the delimiter character
have macro syntax equivalent to, say, ")".
Proposed solution: leave it as is, and put in a stronger warning
about setting it up yourself.
< OK by me. This facility will not be used by the casual user anyway,
and keeping it simple will help to prevent unforseen interactions with
other stuff in the language. >
(12) There have been complaints that letting ~T output two spaces
when the column cannot be determined is relatively useless.
It has been suggested that the behavior for strings be adopted
in all cases where the absolute column cannot be determined:
assume that one is at column zero as of the beginning of the
format operation, and format can keep track of things from there.
Proposed solution: adopt this idea. Put in a note that code will be
portable among more devices if all format strings actually do begin at
column zero or start out with ~% or ~&.
< I'm in favor. But make that note say "... if all format strings
CONTAINING ~T actually do begin at column zero..." >
(13) What should enough-namestring really do?
Proposed solution: change the requirement to:
(merge-pathnames (enough-namestring <pathname> <defaults>) <defaults>)
<=> (merge-pathnames <pathname> <defaults>)
< Looks OK to me. >
(14) Are (terpri) and (write-char #\Return) the same or different?
And what of (format t "~%")? How many characters are in the string "
" ?
< Well, I could live with Guy's proposal, but a bit unhappily. Let me
propose the following slight modification: require every implementation
to recognize NEWLINE as a character name and require (write-char
#\Newline) to be the same as (terpri). There is NO requirement that
#\Return and #\Newline be the same. This will allow (but not require)
implementations to give #\Return and #\Linefeed their traditional ASCII
meanings, and will allow #\Newline to be the magic thing that "does the
right thing" in write-char. For Spice, we have decided to go with the
unix convention of having a single LF between lines in a file, and this
will give us the flexibility to come up with an elegant solution: CR and
LF are the usual ASCII chars, and NEWLINE is the same as LF. >
(15) What are the precise semantics of eval-when?
< We are happy to stick with the model Guy described or to accept minor
variations on this theme. I really don't care what nested EVAL-WHENs
do, so if some slightly different convention makes life easier for other
implementations, I can live with that, as long as it is implementable
and clear. >
∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
∂07-Oct-83 1915 @MIT-ML:Moon@SCRC-TENEX Nasty issues for Common LISP Manual
Received: from MIT-ML by SU-AI with TCP/SMTP; 7 Oct 83 19:14:26 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 7-Oct-83 22:14:08-EDT
Date: Friday, 7 October 1983, 22:09-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: Nasty issues for Common LISP Manual
To: STEELE%CMU-CS-C@MIT-ML
Cc: fahlman%CMU-CS-C@MIT-ML, rpg%SU-AI@MIT-ML, moon@SCRC-TENEX,
dlw@SCRC-TENEX, bsg@SCRC-TENEX
In-reply-to: The message of 7 Oct 83 02:14-EDT from STEELE at CMU-CS-C,
The message of 7 Oct 83 13:07-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Fri 7 Oct 83 02:14:54-EDT
From: STEELE@CMU-CS-C.ARPA
(1) The lexical scope of MACROLET macros. The scope of the defined
names is clearly lexical; there is no problem there. But what is
visible to the *bodies* of the macros defined in a MACROLET?
I don't see that this is much of a problem. There are two sets of
lexical environments involved; the compile-time set and the run-time
set. Obviously the body of a local macro is in the compile-time lexical
environment. The run-time lexical environment does not exist at compile
time; only the compiler's model of what it will be exists. Now, do we
have any special forms that create bindings in the compile-time lexical
environment, or is it always identical to the global environment? A
while back we had a discussion of compiling things like
(LET ((A (FOO)))
(DEFUN BAR ()
...))
I believe we decided that A is bound in a run-time lexical environment,
not a compile-time environment. Then we have to ask what
(MACROLET ((FOO ...))
(DEFUN BAR ()
(MACROLET ((BAZ ...))
...)))
does, specifically whether FOO is defined in the compile-time lexical
environment or the run-time lexical environment or both. I suggest
just the run-time lexical environment.
It's fine with me if we say that there is no way to create local
compile-time lexical environments, so that the compile-time lexical
environment is always the global environment.
There is, of course, one special form that creates a degenerate
compile-time environment that contains only special bindings, not
lexical bindings: COMPILER-LET. No closure is required.
Proposed solution: the bodies of macro-definition functions for
macros defined by macrolet are closed in the global environment,
not in the current lexical environment.
< Actually, given all this scoping hair, I would favor flushing
MACROLET. It is confusing as hell and not very useful. Does anyone
have an important use for this facility? However, I would be willing to
live with the solution above. --SEF>
We have numerous places in "Zetalisp" where we wish we had MACROLET but
have to define some macros and then undefine them (which loses because
you can't do incremental recompilation) or else give them funny names
and hope no one else uses those names (which makes the code
unnecessarily hard to read). So I vote that we keep MACROLET and adopt
Steele's solution of using the global environment with my gloss
explaining why that is obviously the only right thing.
(2) How shall tokens be parsed? The introduction of package syntax has
made this very complicated. It is almost impossible to provide a
coherent explanation of how vertical bars work if vertical bar remains a
macro character. There are also questions of what such tokens as 123:foo
and foo:123 mean.
Back in "Zetalisp", this was simple. Any token that ended in a colon
was a package prefix, regardless of whether up until the colon it looked
like a number or like a symbol; vertical bars were not allowed before
colons; and a package prefix worked by reading one expression relative
to the specified package, regardless of whether it was a symbol, a
number, a list, something involving macro characters, or whatever. Thus
it is quite clear what 123:foo means (the external symbol foo of the 123
package, probably sold by Lotus) and what foo:123 means (same as 123,
numbers don't care about packages).
This got broken and complicated by various "simplifications".
Proposed solution: ...a vertical bar toggles whether you are in vertical-bar
mode, but never terminates the token in and of itself.
Okay. A change, but not a terrible one.
I counterpropose that we return to the "Zetalisp" package prefix syntax,
in other words that we not allow vertical bars to be used around package
names, only around symbol names. This solves #3 as well. I already went
to considerable trouble to implement vertical bars in package-prefix tokens,
but I wouldn't mind ripping that code out again if it made the language
easier to understand and nicer.
If you wish to restrict the successor of a package-prefix token to be
a symbolic token, rather than an arbitrary expression, that's okay with me.
But making them separate tokens simplifies things.
(3) What shall the infix internal package syntax be? Currently it
is "#:".... Another problem is the
confusion of the "#|" reader macro when it encounters "|#" within
|foo|#:|bar|.
Proposed solution: use "::" instead of "#:" for internal package references.
< I have discussed this at some length with Guy, and strongly favor the
change to "::". Again, we are avoiding a lot of conceptual hair by
doing this. --SEF>
I could live with changing #: to ::, although I had hopes to use :: for
something else and the symmetry between infix #: and prefix #: is pleasant.
I would rather keep #: and flush vertical bar in package-prefix tokens.
I don't understand what is the conceptual hair Fahlman alludes to; perhaps
this means non-token-terminating macro characters?
(4) End-of-file and the recursive-p argument. It has been pointed out
that if the recursive-p argument is true and you hit end-of-file, then
you must be in the middle of reading an object, and therefore it is in
order always to signal an error, regardless of the value of eof-errorp of
the top-level call. (However, having the recursive-p argument be true
differs from having eof-errorp be true, because recursive-p also controls
whitespace preservation and the scoping of #n=. Also, the method of
error handling may be interested in being able to locate the top-level
call.)
Proposed solution: adopt this interpretation of recursive-p, changing the
definition on page 290.
< Actually, I think one more epicycle is needed: EOF should be
considered as a terminating character followed by the end of file. If a
terminator would cause the recursive call to exit normally, it does
that, and the EOF problem is worried about by the caller. If you're
down in a recursive-p call in a situation where the terminator would not
exit normally, that's when you ALWAYS signal the error. --SEF>
It is not true that end of file while doing recursive reading is always an
error, as I have pointed out before. Consider the recursive read-char
performed by the semicolon reader-macro; a comment that ends in an end of
file should be as good as a comment that ends in a carriage return followed
by an end of file. Otherwise users of non-record-oriented systems, that don't
force files to end in carriage returns, will think we are stupid. I think
this is what Fahlman is getting at in his comment.
What I said about this last time was a bit confused. Here is a
better proposal. When recursive-p is t, then eof-error-p = nil means
that eof-value should be returned from the inner call to read if it
hits an eof, regardless of the top-level read's arguments; and
eof-error-p = t means that an eof-in-middle-of-object error should
be signalled, again regardless of the top-level read's arguments.
Then fix all examples that say (READ stream NIL NIL T) to be
(READ stream T NIL T).
It may be that only READ-CHAR would ever be called with arguments
of stream NIL eof-value T, and READ would never be called that way, but
they must behave consistently, of course.
Why is "eof-error-p" spelled "eof-errorp"? Isn't that inconsistent with
the new "-p" rules?
(5) How shall #+ and #- operate? In current implementations there is
typically the problem that a strange kind of number or a symbol that
refers to a non-existent package will not be skipped properly even when
conditionalized out by #+ or #-.
Proposed solution: define #+ and #-, when skipping, to perform a READ
operation and then return zero values. All the normal operations of
reading are carried out, including invocation of macro characters,
with the following exceptions:
(a) all tokens are completely uninterpreted and are treated as being NIL;
that is, when a token is scanned, its characters are discarded and
NIL is returned as its value. (This stipulation is important because
user-defined macro characters may read something following, and you have
to say what they see.)
(b) #\ will not complain about reading the name of an unknown character.
(c) #*, #B, #O, #X, #nR will swallow a following token but not complain
about its syntax.
This is the right thing. I would add
(d) #A, #S, "#.", and "#," will read a list but not attempt to interpret
it and build an array or structure, but instead will just read as NIL.
(e) #= is ignored.
(f) ## reads as NIL.
(g) #>, #<return>, etc. continue to signal errors.
An optional sub-proposal, which I will *not* put in, despite the fact
that I favor it, unless you all agree it is a very good thing, is to make
this machinery accessible to the user: stipulate that the function read
takes one more optional argument called suppress-p, and that
macro-character functions receive suppress-p as an additional argument
(this is how #\ can decide whether or not to complain).
This is good. Definitely it should be made available to the user.
(6) Must the compiler preserve the eql-ness of constants defined
by defconstant?
Proposed solution: Yes. The compiler may perform substitutions of
constants only when it can guarantee preservation of the semantics
of defconstant as a global variable whose value is fixed.
This is good. After some experimentation & lossage we settled on this
interpretation of DEFCONSTANT (which already existed internally in
"Zetalisp" under a different name), and experience indicates it is
definitely right.
(7) Must there be a new data type lexical-closure?
Proposed solution: No. Let "closure" be a "conceptual data type".
Sure. We can always "actualize" this data type later if it seems
desirable and the implementors don't mind.
(8) The functions READ-BINARY-OBJECT and WRITE-BINARY-OBJECT are
so general that they are giving implementors fits.
Proposed solution: flush them.
<...having to be able to
read and dump ALL of these data types from ALL kinds of binary streams
creates a huge case analysis task, only a few of whose branches are
useful. --SEF>
We had no trouble at all implementing these. But we did assume that
the stream could accomodate 16-bit bytes, as our default binary streams
do. If one must deal with arbitrary byte sizes it is more painful.
By the way, our write-binary-object ignores the type argument, and
our read-binary-object only uses it for a gratuitous error check, but
I think it is not unreasonable to have those arguments there for other
implementations that might want them.
Leaving things to the second edition is fine with me, especially
inessential things like this. Let's just get this sucker published.
(9) There are arguments to the effect that a single pathname in
*load-pathname-defaults* cannot possibly interact correctly with
both LOAD and COMPILE-FILE. The argument essentially centers
on the use of non-standard file types.
I'd like to see the arguments, since I suspect they are bogus.
There have been other
complaints about this defaulting mechanism as being too restrictive
or culturally incompatible with certain host environments.
Well, the host controls whether the defaults are sticky or not, subject
to override by the user, which seems pretty culturally compatible.
Proposed solution: flush the variables *load-pathname-defaults*,
*compile-file-set-default-pathname*, and *load-set-default-pathname*.
Flush the :set-default-pathname argument to both load and compile-file.
Make the first argument to both load and compile-file be required, not
optional.
Leaving this out and worrying about it in the second edition is fine with me.
Sensible programs always call LOAD with fully-specified pathnames.
(10) There is a functional hole in the language in that there is
no good way to copy a structure. One implementor has proposed that
a function COPY-STRUCTURE is needed. This is not necessarily a
good idea, particularly since there is no STRUCTURE type specifier.
One could also just invent a general COPY function. This has problems,
too.
Proposed solution: let there be a new defstruct option, :COPIER,
analogous to :PREDICATE and :CONSTRUCTOR. If omitted, you get
a simple copying function that is more or less equivalent to
extracting all the fields from the given structure and feeding
their values to the standard constructor.
This sounds good. I would really prefer if all these defstruct-defined
functions defaulted to not being defined unless one specified the appropriate
keyword, rather than defaulting to being defined automatically even if
one doesn't need them.
(11) Should read-delimited-list modify the readtable?
As currently documented, read-delimited-list does *not* modify
the readtable entry for the delimiter character; it is suggested
that this is the responsibility of the user of read-delimited-list.
Others have suggested that read-delimited-list itself should
temporarily, under an unwind-protect, make the delimiter character
have macro syntax equivalent to, say, ")".
Proposed solution: leave it as is, and put in a stronger warning
about setting it up yourself.
Okay. I think Bawden (readermeister) has an opinion about how
read-delimited-list should be implemented, but I don't know what it is,
and he's on vacation for a week.
(12) There have been complaints that letting ~T output two spaces
when the column cannot be determined is relatively useless.
It has been suggested that the behavior for strings be adopted
in all cases where the absolute column cannot be determined:
assume that one is at column zero as of the beginning of the
format operation, and format can keep track of things from there.
Proposed solution: adopt this idea. Put in a note that code will be
portable among more devices if all format strings actually do begin at
column zero or start out with ~% or ~&.
This is good. We'll have to remodularize our FORMAT, which is just as well.
As Fahlman said, only use of ~T (without @) renders this note applicable.
(13) What should enough-namestring really do? It has been pointed out
that if the first argument to enough-namestring is a partially-specified
pathname (missing components) then it cannot possibly obey the given
definition in general.
Proposed solution: change the requirement to:
(merge-pathnames (enough-namestring <pathname> <defaults>) <defaults>)
<=> (merge-pathnames <pathname> <defaults>)
I think this is what I originally meant, but muddled it up. Will this work?
This is the right thing. enough-namestring should return the string with the
fewest characters that satisfies that identity.
(14) Are (terpri) and (write-char #\Return) the same or different?
And what of (format t "~%")? How many characters are in the string "
" ?
Proposed solution: It is imperative that Common LISP shield the
user from character-set problems for ordinary textual cases, even at
the cost of some mapping. Define (terpri) and (write-char #\Return)
to be identical in behavior. Note that (write-char #\Linefeed)
is implementation-dependent; in particular, it is permissible for
an implementation to make (write-line #\Linefeed) emit an ASCII ↑J
unless it immediately follows a (write-line #\Return) for which
the sequence ↑M ↑J was emitted. (This is what MacLISP does.)
This has repercussions on the definition of filepos on text files.
The string "
" may be of length 1 or 2, depending on whether CRLF sequences are
mapped to simply #\Return or not in that implementation. However,
printing such a string will always produce the effect of a single
end-of-line operation.
Note that the internal encoding of #\Return need not be as the ASCII
↑M; indeed, it might well be ↑J! (We should have called it #\Newline,
except for the fact that #\Return reminds people so nicely of the
Return key on most keyboards.)
All this applies only to files opened with :element-type string-char
or character.
This seems like the best compromise.
< Well, I could live with Guy's proposal, but a bit unhappily. Let me
propose the following slight modification: require every implementation
to recognize NEWLINE as a character name and require (write-char
#\Newline) to be the same as (terpri). There is NO requirement that
#\Return and #\Newline be the same. This will allow (but not require)
implementations to give #\Return and #\Linefeed their traditional ASCII
meanings, and will allow #\Newline to be the magic thing that "does the
right thing" in write-char. For Spice, we have decided to go with the
unix convention of having a single LF between lines in a file, and this
will give us the flexibility to come up with an elegant solution: CR and
LF are the usual ASCII chars, and NEWLINE is the same as LF. --SEF>
What about READ-CHAR from the keyboard? Presumably READ-CHAR when the
usual line-terminating key is pressed must return #\Newline, even if
this is not the same character as #\Return but the key has "Return"
engraved on it. What about READ-CHAR from a file stream opened with
element-type STRING-CHAR? Is it required to return exactly one #\Newline
character at the end of each line, or is it allowed to return another
totally random character between lines? I suggest the former. Open
in a non-standard or "binary" mode if you want to see the actual exact
bits in the file, rather than standard character objects.
#\Newline is okay with me provided that Return and Linefeed are REMOVED
from the standard character set. There is no point in providing these
as standard names if what they mean is implementation-dependent. We
should suggest that implementations that use "teletype ascii" and have
these characters should use these particular names for them, and note
that depending on the implementation either name, or neither of them,
can be the same character as #\Newline. Can both of them be the same
character as #\Newline? Presumably not.
We already implement #\Newline, as it turns out! But it isn't the
preferred name on output, since the corresponding key has "Return"
engraved on it, not "Newline."
I cannot find explicit documentation of the Common Lisp character set anywhere
in the manual. I looked in the Characters chapter, the Input/Output chapter,
and the Concept Index. At least fix the index.
(15) What are the precise semantics of eval-when?
The rules Guy described are not what we use in the Lisp machine. The primary
reason for the difference is to avoid the anomaly where compiling
(eval-when (compile load)
(eval-when (compile eval)
(setq x (+ x 1))))
will increment x twice. (There are much worse manifestations of this
anomaly).
The compiler has a state variable called COMPILE-TIME-TOO. (Not a special
variable!) It is initially NIL. Processing of EVAL-WHEN by the compiler
is as follows:
If it contains COMPILE, or if COMPILE-TIME-TOO is true and
it contains EVAL, bind COMPILE-TIME-TOO to true. Otherwise
bind COMPILE-TIME-TOO to false. (When I say "bind", I am
really referring to passing an argument to a recursive call
of the compiler's top-level-form-processing loop.)
If it contains LOAD, process the body forms in the compiler's
normal way, using the new value of COMPILE-TIME-TOO.
If it does not contain LOAD, then if the new value of
COMPILE-TIME-TOO is true, EVAL the body forms, otherwise ignore them.
Processing of other forms by the compiler is as follows:
If COMPILE-TIME-TOO is true, call EVAL on the form.
Then do normal compiler processing of the form.
(Note that there is no place where a form gets processed twice
other than the immediately-preceding two lines.)
I think this is actually simpler than what Guy described.
The actual code is more complicated, with three states for COMPILE-TIME-TOO,
but there is no good reason for this, it's just due to the modularity of the
way macros and declarations are placed into just the compiler's database (not
into the compile-time Lisp interpreter's data base) unless surrounded by
an (EVAL-WHEN (COMPILE)...). This should be part of "then do normal compiler
processing of the form", except that doing it that way would be slightly
less general and modular since the compiler would have to know the names
of all the forms that put things into the compiler's database. Like many
ancient holdovers in the Lisp machine compilers, this is totally insane,
since it turns out it has to know their names anyway to manipulate the
third state of COMPILE-TIME-TOO correctly!
The compiler may choose to apply MACROEXPAND or MACROEXPAND-1 to
a form at any time in order to determine what kind of form it is,
and it must do so before deciding that a form is not of a certain
kind (such as EVAL-WHEN or DEFMACRO).
Yes.
I hope it didn't take you as long to read this message as it took me to write it!
∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
∂08-Oct-83 0120 FAHLMAN@CMU-CS-C.ARPA Nasty issues for Common LISP Manual
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Oct 83 01:19:21 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Oct 83 04:21:01-EDT
Date: Sat, 8 Oct 1983 04:20 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX@MIT-ML.ARPA>
Cc: bsg%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA,
fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, STEELE@CMU-CS-C.ARPA
Subject: Nasty issues for Common LISP Manual
In-reply-to: Msg of 7 Oct 1983 22:09-EDT from David A. Moon <Moon at SCRC-TENEX>
Now that we've heard from Steele, me, and Moon, let me try to sift out
the issues where at lest the three of us seem to agree and the issues where
there are some rough edges. We seem to have problems on issues 5 and
14. Tuning is needed on 4.
(1) Macrolet ought to stay around, I guess. The bodies see a global
(empty) lexical environment, the only one you can get at compile-time.
Some version of Moon's analysis of this might want to go into the
manual.
(2) I don't think that we can accept Moon's suggestion that we revert to
the allegedly simpler Zetalisp syntax for packages. It wouldn't bother
me to do so -- I don't think we want to encourage people to put weird
characters in package names anyway -- but a few people were very adamant
about this when it was on the ballot, and it got discussed at
considerable length. A proposal to change this in some drastic way
would require the same sort of discussion, I think.
Moon seems willing to agree with Guy's proposal on vertical bars, as am I.
(3) If we agree not to attempt the major syntax simplification Moon
proposes in issue 2, then it seems ot me that :: is preferable to #:
because it avoids the ugly interaction with #|...|# and the need to make
# a non-terminating macro character. Moon says he is willing to go along,
though it's not his first choice.
(4) I think that Moon's proposal below would work. I'll have to think
harder about this tomorrow.
What I said about this last time was a bit confused. Here is a
better proposal. When recursive-p is t, then eof-error-p = nil means
that eof-value should be returned from the inner call to read if it
hits an eof, regardless of the top-level read's arguments; and
eof-error-p = t means that an eof-in-middle-of-object error should
be signalled, again regardless of the top-level read's arguments.
Then fix all examples that say (READ stream NIL NIL T) to be
(READ stream T NIL T).
It may be that only READ-CHAR would ever be called with arguments
of stream NIL eof-value T, and READ would never be called that way, but
they must behave consistently, of course.
(5) I said before that we were unwilling to implement a whole separate
reader just to get various special cases to work right in #+ and #-,
evil constructs whose syntax cannot be made to work in general.
Somebody proposed one exception (don't complain about unknown packages)
and I agreed. Guy just proposed seven more exceptions, and I got scared.
Now Moon wants another seven, and if these get in there are sure to be
128 more. I think that the camel's back just broke.
We should say that #+ and #- are worthless crocks kept around for
historical reasons, and that they do a very dumb thing: just call READ
and discard the result. No exceptions. If you want to conditionally
read hairy things without getting syntax errors, you have to use
something like the #0+ I proposed earlier, which gobbles a string
delimited by double-quotes and conditionally passes the result to the
reader. I agree that #0+ and #0- are hideous, so I propose #W for the
#+ analogue and #U for the #- analogue. W stands for for "when" and U
for "unless". Neither char is used in Common Lisp sharp macros right
now -- does anyone have a conflict?
(6) Looks like we all agree on Guy's proposal for the semantics of
DEFCONSTANT.
(7) Looks like we all agree that there is no pressing need for a lexical
closure data-type, but that whatever is returned for a lexical closure
must be an instance of FUNCTION.
(8) No two people seem to interpret the manual the same way with respect
to READ/WRITE-BINARY-OBJECT. Glad everyone is willing to go along with
flushing these things from the white-pages for now. However, the
"official" interpretation might be clarified, some groups would have to
completely re-do their implementation. Dike it out.
(9) Guy and I want to flush the *load-pathname-defaults* stuff and Moon
is willing to go along.
(10) Everyone seems willing to go along with Guys :COPIER proposal. I
agree with Moon that some of these defstruct-defined functions should
not exist by default, but that's not a change we want to consider now,
is it?
(11) Should read-delimited-list modify the readtable?
Everyone seems to be willing to live with Guy's proposal that it does
not do this, and that the burden of readtable hacking falls on the user.
(12) Everyone seems happy with the proposal to have ~T assume that the
format started in column 0 if it cannot find out for sure.
(13) Everyone seems happy with Guy's clarification of ENOUGH-NAMESTRING.
(14) This is complicated.
#\Newline is okay with me provided that Return and Linefeed are REMOVED
from the standard character set. There is no point in providing these
as standard names if what they mean is implementation-dependent. We
should suggest that implementations that use "teletype ascii" and have
these characters should use these particular names for them, and note
that depending on the implementation either name, or neither of them,
can be the same character as #\Newline. Can both of them be the same
character as #\Newline? Presumably not.
OK, if we want to hide character-set differences under READ-CHAR
and WRITE-CHAR, and to have everything be portable from there on up, I
guess we agree that #\Newline is the character used to separate lines,
and that #\Return and #\Linefeed are not part of the standard character
set and should be avoided in portable code. An implementation is free
to provide these as non-standard extensions, along with all sorts of
other ugly cursor-control codes, but only #\newline has the seal of
approval for portable code.
I'm not really sure what READ-CHAR from the keyboard should do. In our
implementation the RETURN key would normally be read in as a random code
that is a command for Hemlock, telling it to break the line, and some
other characters might break the line in different ways. If the Hemlock
buffer gets passed on to Lisp via a character stream, that line break
would show up as a #\newline, but when Lisp sucks raw characters from the
keyboard it is unclear to me that "the usual line-terminating key" is a
well-defined concept. This might well vary according to what you are
doing.
I think the reason this is hard is that the things coming from a
keyboard should not be considered to be the same as normal characters
from a character-type stream. They are keystroke-objects or something,
and only keystroke objects have "bits" like meta and super. Keyboard of
reading is more like reading from a binary stream than like reading
characters from a file -- a mapping has to be done before you have a
character stream. Maybe the right move is to say that in reading a
character stream -- the only stream type for which READ-CHAR and
WRITE-CHAR are defined, #\Newline is indeed the convention, and that
"civilized" keyboard input can be obtained that way, but that "raw mode"
keyboard input is implementation-dependent and does not necessarily come
in via a character stream. Bleh!
(15) If I understand what Moon is saying about their treatment of
EVAL-WHEN, I think I can implement the same thing and I think it will
work OK. I'm not passionate about this stuff, as long as I can see what
to implement and it's not too hairy. I'm not sure exactly how much of
this wants to be specified by the manual. Any proposals for what to
say?
-- Scott
∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
∂08-Oct-83 0831 FAHLMAN@CMU-CS-C.ARPA Nasty issues for Common LISP Manual
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Oct 83 08:31:44 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Oct 83 11:33:32-EDT
Date: Sat, 8 Oct 1983 11:33 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: bsg%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA,
David A. Moon <Moon%SCRC-TENEX@MIT-ML.ARPA>, rpg@SU-AI.ARPA,
STEELE@CMU-CS-C.ARPA
Subject: Nasty issues for Common LISP Manual
In-reply-to: Msg of 8 Oct 1983 04:20-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
I just re-read my note of last night. While I still believe the content
of what I said, I apologize for the number of typos and
ungrammaticalities. When you're tired, I/O seems to be the thing
that breaks.
One sentence is so messed up that it might be misinterpreted:
However, the "official" interpretation might be clarified, some groups
would have to completely re-do their implementation.
should have been
However the "official" interpretation might be clarified, some groups
would have to completely re-do their implementation.
-- Scott
∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
∂08-Oct-83 1237 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Nasty issues for Common LISP Manual
Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Oct 83 12:37:26 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 8-Oct-83 15:39:13-EDT
Date: Saturday, 8 October 1983, 15:41-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Nasty issues for Common LISP Manual
To: Scott E. Fahlman <Fahlman@CMU-CS-C>, Dick Gabriel <RPG@SU-AI>,
STEELE@CMU-CS-C
Cc: moon%SCRC-TENEX@MIT-MC, bsg%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC
In-reply-to: The message of 8 Oct 83 04:20-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 8 Oct 83 11:33-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 8 Oct 83 13:16-EDT from Dick Gabriel <RPG at SU-AI>
Looks like we are in general agreement.
I'd prefer to get rid of the vertical bars in package prefixes, but I guess
I can live with keeping this crockish syntax and switching #: to :: if I have to.
I still think that's an inferior choice.
As far as #+ and #- go, I am adamantly opposed to introducing new syntax for
the same functionality. I don't think I was introducing additional exceptions;
I was trying to make Steele's suggested interpretation of how the reader skips
over an expression more consistent. I don't think there is anything complicated
or scary here; basically while reading the expression after an unsatisfied #+,
tokens are scanned and read as NIL, and built-in macros read whatever their
syntax is then return NIL, without performing any side-effects. Maybe instead
of enumerating them one by one we should simply state a general rule this way.
User macros get the suppress-p argument and are encouraged to do the same thing
as built-in macros.
I agree with RPG that first-class lexical closures are an important part of
the language. Since they are an innovation in the Maclisp family, we want to
be a bit cautious about just what we standardize. Everyone is in agreement.
I made an error in my discussion of #\Newline; everywhere where I said
"the keyboard" please substitute "the stream that is the value of *TERMINAL-IO*
and the initial value of *STANDARD-INPUT*". Indeed one wants a way to really
get at the exact keystrokes on the keyboard, something we haven't tried to
standardize yet.
∂10-Oct-83 2321 RPG Nasty issues for Common LISP Manual
∂08-Oct-83 1329 FAHLMAN@CMU-CS-C.ARPA Nasty issues for Common LISP Manual
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Oct 83 13:26:34 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 8 Oct 83 16:27:49-EDT
Date: Sat, 8 Oct 1983 16:27 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
Dick Gabriel <RPG@SU-AI.ARPA>, STEELE@CMU-CS-C.ARPA,
fahlman@CMU-CS-C.ARPA
Subject: Nasty issues for Common LISP Manual
In-reply-to: Msg of 8 Oct 1983 15:41-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-MC>
As far as #+ and #- go, I am adamantly opposed to introducing new syntax for
the same functionality. -- Moon
Well, I was proposing that we introduce a single workable syntax for
what one really wants #+ and #- to do: read some stuff or not, depending
on what system you are using. The historical syntax of #+ and #- is
unfortunately unworkable, except for the simplest of cases. Since I
have proposed what I believe to be a simple, clean, elegant solution
that does the right thing and is trivial to implement, I am adamantly
opposed to doing a lot of work in the reader to make a few more cases
work properly in old-style #+ and #-. Moon says that he is proposing a
single principle rather than a lot of specific exceptions. That may be,
but the fact remains that to put in this suppress-p machinery, we would
have to change about thirty places in our reader.
I could live with that, though it would irritate me mightily -- I hate
patching up crocks when a clean solution to the problem is evident. But
if we go that far, I am afraid that it will appear that we are endorsing
the principle that #+ and #- have to read the next Lisp object without
complaining and without side effects, regardless of how complicated that
gets. Users will start expecting that and reporting violations as bugs.
I'm not willing to buy into that, because it can get very complicated
indeed, and can never be completely right in all cases.
In the #U and #W proposal, I am not proposing ADDITIONAL syntax for the
same functionality. I am proposing that we introduce a single decent
functionality and phase out the old broken one. Probably the best thing
to do, if the world were young, would be to take the #+ and #- characters
for the new syntax and flush the old one right now, but I didn't propose
that because it would cause Symbolics a lot of trouble and would send
RMS into a veritable meltdown. We don't have any old code around that
hasn't been rewritten, so it wouldn't bother us.
-- Scott
∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
∂08-Oct-83 2128 Guy.Steele@CMU-CS-A Yet another proposal for #+ and #-
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 8 Oct 83 21:28:47 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 9 Oct 83 00:14:03 EDT
Date: 9 Oct 83 0024 EDT (Sunday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, dlw%scrc-tenex@MIT-ML,
moon%scrc-tenex@MIT-ML, bsg%scrc-tenex@MIT-ML
Subject: Yet another proposal for #+ and #-
Flush them.
I'm serious. How many of you would find it more objectionable to
eliminate #+ and #- from the white pages than to standardize on
whatever you perceive to be "the wrong thing"?
--Guy
∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
∂08-Oct-83 2138 FAHLMAN@CMU-CS-C.ARPA Yet another proposal for #+ and #-
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Oct 83 21:38:11 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Oct 83 00:39:46-EDT
Date: Sun, 9 Oct 1983 00:39 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
moon%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA, fahlman@CMU-CS-C.ARPA
Subject: Yet another proposal for #+ and #-
In-reply-to: Msg of 9 Oct 83 0024 EDT () from Guy.Steele at CMU-CS-A
Flushing these things from the white pages sounds good to me. Then
people with bootstrapping problems or multiple systems could do whatever
they need to do, and portable Common Lisp code would be devoid of these
"features".
-- Scott
∂10-Oct-83 2321 RPG Yet another proposal for #+ and #-
∂08-Oct-83 2219 FAHLMAN@CMU-CS-C.ARPA Yet another proposal for #+ and #-
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Oct 83 22:18:55 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 9 Oct 83 01:20:36-EDT
Date: Sun, 9 Oct 1983 01:20 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
Guy.Steele@CMU-CS-A.ARPA, moon%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Yet another proposal for #+ and #-
In-reply-to: Msg of 9 Oct 1983 00:39-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Presumably if #+ and #- are dropped from the white pages, *FEATURES*
should be too. That gets rid of the issue of whether the entries on
this list are symbols, keywords, or arbitrary objects.
-- Scott
∂10-Oct-83 2322 RPG Yet another proposal for #+ and #-
∂09-Oct-83 1243 @MIT-MC:Moon@SCRC-TENEX Yet another proposal for #+ and #-
Received: from MIT-MC by SU-AI with TCP/SMTP; 9 Oct 83 12:43:36 PDT
Received: from scrc-euphrates by scrc-vixen with CHAOS; 9 Oct 1983 15:36:20-EDT
Date: Sunday, 9 October 1983, 15:35-EDT
From: David A. Moon <Moon at SCRC at mit-mc>
Subject: Yet another proposal for #+ and #-
To: Guy.Steele at CMU-CS-A at mit-mc, Scott E. Fahlman <Fahlman at CMU-CS-C at mit-mc>
Cc: rpg at SU-AI at mit-mc, dlw at SCRC at mit-mc, moon at SCRC at mit-mc, bsg at SCRC at mit-mc
In-reply-to: The message of 9 Oct 83 00:24-EDT from Guy.Steele at CMU-CS-A,
The message of 9 Oct 83 00:39-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 9 Oct 83 01:20-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: 9 Oct 83 0024 EDT (Sunday)
From: Guy.Steele@CMU-CS-A
Flush them.
I'm serious. How many of you would find it more objectionable to
eliminate #+ and #- from the white pages than to standardize on
whatever you perceive to be "the wrong thing"?
Date: Sun, 9 Oct 1983 00:39 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Flushing these things from the white pages sounds good to me. Then
people with bootstrapping problems or multiple systems could do whatever
they need to do, and portable Common Lisp code would be devoid of these
"features".
Date: Sun, 9 Oct 1983 01:20 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Presumably if #+ and #- are dropped from the white pages, *FEATURES*
should be too. That gets rid of the issue of whether the entries on
this list are symbols, keywords, or arbitrary objects.
Do you realize how insane this sounds? What possible point is there in
having a syntactic feature to allow the same source program to run on
multiple implementations that are not completely compatible with each
other, if that very syntactic feature is not itself compatible between
all implementations?? It makes no sense at all!
Face it: the various Common Lisp implementations will not be 100%
compatible. People who are trying to write programs that are both
complex and efficient are going to have some implementation-dependent
sections. Program maintenance is much easier if a common source file
can be compiled for all implementations. Much hiding of
implementation-dependent features can be done with macros, but not
everything can be done that way. Having two slightly-differing versions
of the same function in different files, because the reader won't
allow them to be placed together, is an excellent way to ensure
divergence of implementation-dependent versions and eventual
non-maintainability. I speak from experience on this point.
The #+ and #- features are extremely simple, extremely easy to
implement, and rather easy to explain, much more so than a myriad of
other Common Lisp features. Flushing them is not good policy.
∂10-Oct-83 2322 RPG Binding arbitration?
∂10-Oct-83 0924 FAHLMAN@CMU-CS-C.ARPA Binding arbitration?
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 10 Oct 83 09:23:53 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Oct 83 12:25:23-EDT
Date: Mon, 10 Oct 1983 12:25 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: moon%SCRC-TENEX@MIT-ML.ARPA
Cc: bsg%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA,
steele@CMU-CS-C.ARPA, fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA
Subject: Binding arbitration?
In-reply-to: Msg of 9 Oct 1983 16:54-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Guy has to finalize the manual tomorrow, and I don't want the stupid #+
business to delay that. Unless my last message persuaded Moon of the
beauty and elegance of #U and #W, which I doubt, we seem to have reached
an impasse -- a fundamental divergence in taste, I guess. I propose
that we settle the matter by vote of three tasteful and impartial
referees: Steele, DLW, and RPG. I have not heard from any of the three
on this issue. If 2/3 of them think that patching #+ and #- is the more
tasteful way to go, I will go along with that, for the first edition at
least. If 2/3 of them think that #U and #W are preferable and that #+
and #- should be phased out of Common Lisp, I hope that Moon will go
along. From his messages, it seems that there is no technical problem
with this course, but that he objects strongly on the grounds of taste.
I hope that all three judges are available for a quick vote, and not
off on vacation or something. If DLW is unavailable, BSG would be an
acceptable substitute.
There are two proposals on the table. The first says that we add an
optional suppress-p argument to the various READ functions, and that
anyone who wants to read something harmlessly, with the results to be
discarded, should call READ with that switch on. This would disable
error signalling in the cases listed earlier by Steele and Moon, and
would cause certain calls to return NIL instead of whatever they read.
The second proposal says that #W and #U would read a symbol and look for
it on the *features* list, just like #+ and #- do now. However, instead
of calling read with suppress-p to get the next thing, they simply call
read. The next item has to be a string, else an error is signalled.
The contents of that string are then conditionally sent to the reader,
depending on whether the control symbol was found on *features*, and the
results of that read are returned. (Probably best to just allow one
Lisp object in the string, though the syntax could support more than
one.) The advantage is that stuff in the string never gets processed by
the reader if it is not supposed to, so we read or skip the item very
cleanly. The disadvantage is that this uses up two more macro
characters, though #+ and #- could eventually be recycled, and that it
is a break with the past in an area where compatibility is useful.
As I said, if the judges rule in favor of #+ and #-, we will implement
them as specified in Moon's earlier mail, though I would like the manual
to mention that we can not guarantee to read ANY lisp object without
complaint.
-- Scott
∂10-Oct-83 2322 RPG Binding arbitration?
∂10-Oct-83 1054 @MIT-MC:BSG%SCRC-TENEX@MIT-MC Binding arbitration?
Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Oct 83 10:54:13 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Mon 10-Oct-83 13:56:25-EDT
Date: Monday, 10 October 1983, 13:54-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: Binding arbitration?
To: Fahlman@CMU-CS-C, moon%SCRC-TENEX@MIT-MC
Cc: dlw%SCRC-TENEX@MIT-MC, steele@CMU-CS-C, rpg@SU-AI
In-reply-to: The message of 10 Oct 83 12:25-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Mon, 10 Oct 1983 12:25 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Guy has to finalize the manual tomorrow, and I don't want the stupid #+
business to delay that. Unless my last message persuaded Moon of the
beauty and elegance of #U and #W, which I doubt, we seem to have reached
an impasse -- a fundamental divergence in taste, I guess. I propose
that we settle the matter by vote of three tasteful and impartial
referees: Steele, DLW, and RPG. I have not heard from any of the three
on this issue. If 2/3 of them think that patching #+ and #- is the more
tasteful way to go, I will go along with that, for the first edition at
least. If 2/3 of them think that #U and #W are preferable and that #+
and #- should be phased out of Common Lisp, I hope that Moon will go
along. From his messages, it seems that there is no technical problem
with this course, but that he objects strongly on the grounds of taste.
I hope that all three judges are available for a quick vote, and not
off on vacation or something. If DLW is unavailable, BSG would be an
acceptable substitute.
Whether or not DLW replies, I agree with Moon fully. The #W proposal, although
not completely lacking in appeal, will create hideous multiply-quoted
unreadable junk.
The proposals to flush read-time conditionalization are patently unacceptable.
Moon's remarks on source maintenance are completely in agreement with
my own opinions on the subject.
∂10-Oct-83 2322 RPG #W etc
∂10-Oct-83 1507 RPG@SU-SCORE.ARPA #W etc
Received: from SU-SCORE by SU-AI with TCP/SMTP; 10 Oct 83 15:07:35 PDT
Date: Mon 10 Oct 83 14:01:29-PDT
From: Dick Gabriel <RPG@SU-SCORE.ARPA>
Subject: #W etc
To: dlw%scrc-tenex%MIT-MC@MIT-XX.ARPA, fahlman@CMU-CS-C.ARPA,
steele@CMU-CS-C.ARPA, moon%scrc-tenex%MIT-MC@MIT-XX.ARPA
cc: rpg@SU-AI.ARPA
Several things. First we need something like #+ and friends for
the near-term when MacLisp code will co-exist with Common Lisp code.
Second, I don't like the names #W and #U because I, and I suspect others,
will find it hard to recall what they mean. Third, I like not having
to enclose code with ".." Fourth, I don't like having to hair up
a possibly already-slow reader to give the user supress-p control,
though I like giving the user a handle on many things. So, I'm willing
to let the reader be haired-up and to go with #+ and #- over #W and #U,
and to live with suppress-p. This is not to say that I don't think there
is an elegance to Scott's #W proposal.
-rpg-
-------
∂10-Oct-83 2322 RPG #+foo
∂10-Oct-83 1752 FAHLMAN@CMU-CS-C.ARPA #+foo
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 10 Oct 83 17:52:20 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 10 Oct 83 20:53:59-EDT
Date: Mon, 10 Oct 1983 20:53 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA, moon%SCRC-TENEX@MIT-ML.ARPA,
bsg%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA, rpg@SU-AI.ARPA
Cc: fahlman@CMU-CS-C.ARPA
Subject: #+foo
In-reply-to: Msg of 10 Oct 1983 13:54-EDT from Bernard S. Greenberg <BSG%SCRC-TENEX at MIT-MC>
OK, the time to settle this is upon us. Given the preference for #+/#-
expressed by BSG and RPG, and a bug that someone pointed out today in
the #U/#W syntax, I'm ready to throw in the towel. (The bug is that the
/ vs. \ business still causes trouble because it interacts with the ""
syntax for strings. This is also a problem for the old syntax in some
cases, but it is no longer perfect versus imperfect.)
We'll agree to #+ and #- with the suppress-p mechanism proposed
by Moon and Steele. I would only request that this be described in a
narrow way in the manual so that users do not get the idea that we are
willing to extend this mechanism ad infinitum to make more and more odd
cases "work".
-- Scott
∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
∂10-Oct-83 2027 Guy.Steele@CMU-CS-A Monkey wrench from left field (#+ and #-)
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 10 Oct 83 20:27:23 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 10 Oct 83 23:16:17 EDT
Date: 10 Oct 83 2326 EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, bsg%scrc-tenex@MIT-ML,
moon%scrc-tenex@MIT-ML, dlw%scrc-tenex@MIT-ML, rpg@SU-AI
Subject: Monkey wrench from left field (#+ and #-)
Okay, guys, here is a (literally) eleventh-hour proposal for #+ and #-.
Pick some other random sharp-sign combination, say "#;", for a delimiter.
Then define the action of #+ (and similarly #-) as follows:
If the feature spec is true, then read one form, then peek ahead and
insist on finding "#;", which is swallowed, then return the form read.
If the feature spec is false, then skip over arbitrary text that is
balanced in "#+"/"#-" and "#;" until the closing #; is seen and swallowed,
and then return no values. For robustness, "#;", like "#)" and others,
has a definition that complains if read by itself.
Example: (setq x #+SPICE 1.0L15000 #;
#-SPICE #-LISPM #-EBCDIC #o40 #;
#+EBCDIC #x40 #;
#;
#+LISPM #\Hyper-Space #;
#;)
This scheme has the following advantages:
(1) It's just like the current scheme except that you have to sprinkle
in some extra gritches ("#;").
(2) It can skip over almost any text.
(3) There is a gritch explicitly delimiting the end of the conditionalized
text, so it's easy to see exactly what falls under the condition.
(Compare the above example with this:
(setq x #+SPICE 1.0L15000
#-SPICE #-LISPM #-EBCDIC #o40
#+EBCDIC #x40
#+LISPM #\Hyper-Space )
Even with the indentation, I judge this harder to read.)
(4) It does not interact with other syntaxes very much, so it can be thrown
around any form with almost complete impunity. (One problem with the #W/#U
proposal is that any form that had "..." thrown around it would have to have
any double-quotes within it escaped with a backslash.)
(5) It is almost completely backwards compatible, in that if one made "#;"
have a macro definition that did nothing (like ; but swallows no additional
text) in, for example, MacLISP, then MacLISP could swallow this syntax
too, except that it would have the old bug it always had of not being able to
skip over an unreadable syntax.
What do you all think?
--Guy
∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
∂10-Oct-83 2131 FAHLMAN@CMU-CS-C.ARPA Monkey wrench from left field (#+ and #-)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 10 Oct 83 21:31:18 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 11 Oct 83 00:32:41-EDT
Date: Tue, 11 Oct 1983 00:32 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
moon%scrc-tenex@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Monkey wrench from left field (#+ and #-)
In-reply-to: Msg of 10 Oct 83 2326 EDT () from Guy.Steele at CMU-CS-A
Guy,
I like your new proposal better than the existing #+/#-, since it solves
the same problem I was trying to solve with my ill-fated proposal, only
better. I would not dwell heavily on the ability to nest these things
in explaining this -- we don't want the users going overboard -- but
it's nice to have that capability available when you need it.
Obviously I'm not the one who will be hard to convince on this one.
It's the people with lots of inherited code, and therefore the need to
put in lots of "gritches", who might object. If those
ultra-conservatives at SYmbolics go along with this, then we've got a
winner.
-- Scott
∂10-Oct-83 2323 RPG Monkey wrench from left field (#+ and #-)
∂10-Oct-83 2132 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Monkey wrench from left field (#+ and #-)
Received: from MIT-MC by SU-AI with TCP/SMTP; 10 Oct 83 21:31:53 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 11-Oct-83 00:36:11-EDT
Date: Tuesday, 11 October 1983, 00:33-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: Monkey wrench from left field (#+ and #-)
To: Guy.Steele@CMU-CS-A
Cc: Scott.Fahlman <FAHLMAN@CMU-CS-C>, bsg%SCRC-TENEX@MIT-MC,
dlw%SCRC-TENEX@MIT-MC, rpg@SU-AI
In-reply-to: The message of 10 Oct 83 23:26-EDT from Guy.Steele at CMU-CS-A
Date: 10 Oct 83 2326 EDT (Monday)
From: Guy.Steele@CMU-CS-A
Okay, guys, here is a (literally) eleventh-hour proposal for #+ and #-.
Pick some other random sharp-sign combination, say "#;", for a delimiter.
Then define the action of #+ (and similarly #-) as follows:
If the feature spec is true, then read one form, then peek ahead and
insist on finding "#;", which is swallowed, then return the form read.
If the feature spec is false, then skip over arbitrary text that is
balanced in "#+"/"#-" and "#;" until the closing #; is seen and swallowed,
and then return no values. For robustness, "#;", like "#)" and others,
has a definition that complains if read by itself.
Example: (setq x #+SPICE 1.0L15000 #;
#-SPICE #-LISPM #-EBCDIC #o40 #;
#+EBCDIC #x40 #;
#;
#+LISPM #\Hyper-Space #;
#;)
If you must have grouping, how about:
(setq x #+SPICE 1.0L15000
#+LISPM #\Hyper-Space
#+(AND (NOT LISPM) (NOT SPICE) (NOT EBCDIC)) #o40
#+(AND (NOT LISPM) (NOT SPICE) EBCDIC) #x40)
Look, I'd really prefer that we keep #+ and #- simple like they were
intended to be. Let's not introduce new syntax that allows/requires
people to write unreadable messes such as your example above. It's
not necessary to be able to implement Turing machines in #+/#- language.
It's not even necessary to be able to write arbitrarily complex
conditionals in the minimum number of characters. People don't
write arbitrarily-complex conditionals with #+; they write
simple ones. At Symbolics we considered allowing you to write
(make-array 500 #2+LISPM :area disaster-area)
and rejected it, requiring you to write the more verbose but
easier to understand and explain
(make-array 500 #+LISPM :area #+LISPM disaster-area)
Another thing we rejected is
(make-array 500 #0+LISPM(:area disaster-area))
If you can't understand why we rejected these, think about it for
a few days.
This whole business with suppressing read errors while inside
a failing #+ has gotten totally out of hand. All it was supposed
to be is a very simple kludge so that one need not be bothered with
obviously pointless error messages caused by floating-point overflow
in numeric constants intended for other implementations; the same
consideration applies to character constants and external-symbol
references using package prefixes. There is no real need to be
able to skip over arbitrary Cobol programs in the middle of a Lisp
program, so let's not make life more difficult for the Lisp programmer
just to support something no one will ever need. Let's simply make
it that inside a failing #+ READ will parse expressions but not
interpret them.
Actually I don't think the 11th hour is 11 pm. More like 5 pm, unless
my memory is broken. Just before sundown if you're at a Mediterraneanly
low latitude.
∂10-Oct-83 2323 RPG #+ and #- syntax
∂10-Oct-83 2234 Guy.Steele@CMU-CS-A #+ and #- syntax
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 10 Oct 83 22:33:53 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 11 Oct 83 01:22:01 EDT
Date: 11 Oct 83 0132 EDT (Tuesday)
From: Guy.Steele@CMU-CS-A
To: rpg@SU-AI, Scott.Fahlman <FAHLMAN@CMU-CS-C>, moon%scrc-tenex@MIT-ML,
dlw%scrc-tenex@MIT-ML, bsg%scrc-tenex@MIT-ML
Subject: #+ and #- syntax
:-) How about
(setq x #+(and lispm gritches) #\Hyper-Space #;
#+(and lispm (not gritches)) #\Hyper-Space
)
... no, I guess that wouldn't work, would it?
Seriously, folks, it looks like it was a bad idea, and I retract
the suggestion. (Those of you familiar with constraint languages
know that that means it disappears unless someone else supports
it independently.) It looks like our best bet is the straight
existing #+/#- syntax with the suppress-p thing.
--Guy
∂12-Oct-83 0642 Meehan@YALE SETF and Prolog
Received: from YALE by SU-AI with TCP/SMTP; 12 Oct 83 06:42:04 PDT
Received: by YALE-BULLDOG via CHAOS; Wed, 12 Oct 83 09:45:40 EDT
Date: Wed, 12 Oct 83 09:39:39 EDT
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: SETF and Prolog
To: common-lisp@SU-AI.ARPA
As long as you're doing (SETF (+ X 3) 10), why not use SETF as a
notation for Prolog-style assertions? E.g.,
(SETF (GRANDFATHER-OF X) 'THOMAS).
(-: There. We embedded it again. :-)
-------
∂12-Oct-83 1056 LES@CMU-CS-C.ARPA Re: SETF and Prolog
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Oct 83 10:52:54 PDT
Received: ID <LES@CMU-CS-C.ARPA>; Wed 12 Oct 83 13:54:38-EDT
Date: Wed 12 Oct 83 13:54:37-EDT
From: LES@CMU-CS-C.ARPA
Subject: Re: SETF and Prolog
To: Meehan@YALE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Jim Meehan <Meehan@YALE.ARPA>" of Wed 12 Oct 83 09:50:24-EDT
Assuming that x has the structure of a person, i.e. that you use a defstruct
to define what a person is, then the setf form for the grandfather field
is well defined. Something like:
(defstruct person (:conc-name nil ...)
.
.
(grandfather-of nil)
.
.
)
Will make the supplied setf form entirely valid.
-Lee
-------
∂13-Oct-83 1051 GALWAY@UTAH-20.ARPA SETF and LAMBDAs (semi-serious?)
Received: from UTAH-20 by SU-AI with TCP/SMTP; 13 Oct 83 10:51:37 PDT
Date: Thu 13 Oct 83 11:53:06-MDT
From: William Galway <Galway@UTAH-20.ARPA>
Subject: SETF and LAMBDAs (semi-serious?)
To: Common-Lisp@SU-AI.ARPA
All this discussion about the power of SETF has reminded me of an
idea that I've been toying with for awhile. Basically, I'd like
to modify the lambda calculus to allow non-atomic "arguments" for
the lambda. So, in addition to things like:
(lambda (x)
(lambda (y)
x))
(the K combinator, I think), it would also be legitimate to have
things like:
(lambda (x)
((lambda ((y x)) (y x))
x))
(which I think would be the identity function).
I don't claim that there's any good reason for doing this--it just seemed
like a natural thing to do during one of my weirder moments. If anyone
knows if work has already been done with this funny variant of the lambda
calculus, I'd be interested in hearing about it.
On the other hand, if we leave the world of pure mathematical systems and
enter the world of Lisp, it does kind of appeal to me to be able to write
code like:
(let (
((elt v 0) (length v)))
v)
but, I'm not seriously suggesting that it be implemented...
-- Will Galway
-------
∂13-Oct-83 1232 @MIT-MC:MOON@SCRC-TENEX SETF and LAMBDAs (semi-serious?)
Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Oct 83 12:32:01 PDT
Date: Thursday, 13 October 1983 14:39-EDT
From: MOON at SCRC-TENEX
To: William Galway <Galway at UTAH-20.ARPA>
Cc: Common-Lisp at SU-AI.ARPA
Subject: SETF and LAMBDAs (semi-serious?)
In-reply-to: The message of Thu 13 Oct 83 11:53:06-MDT from William Galway <Galway@UTAH-20.ARPA>
This was implemented in Maclisp under the name of "destructuring LET".
It raises a number of complicated issues that I don't think we should get
involved in right now. Note, as just one example, that you were not
consistent with yourself in the examples you give of what it might do.
Your first example
(lambda (x)
((lambda ((y x)) (y x))
x))
seems to expect the argument to be a list of two elements, where y
is bound to the first element and x is bound to the second. In other
words the "pattern" in the lambda-expression is a piece of data acting
as a template. Unless I misunderstand the example completely, which
is possible since it certainly isn't written in Common Lisp.
In your second example,
(let (
((elt v 0) (length v)))
v)
the "pattern" in the lambda-expression (a let this time) is a piece of
code describing a location to be stored into. I won't even go into the
deeper semantic issues raised by your second example; the syntactic
issues are enough to show that it is complicated.
Note that if you add a new special form (a macro) to the language,
rather than redefining existing things such as let and lambda, you
can experiment with various versions of such things in any Common Lisp
implementation, or any other reasonable Lisp implementation, without
any need to change the compiler, interpreter, or run-time.
∂13-Oct-83 1851 GALWAY@UTAH-20.ARPA Whoops (SETF and LAMBDAs)
Received: from UTAH-20 by SU-AI with TCP/SMTP; 13 Oct 83 18:51:18 PDT
Date: Thu 13 Oct 83 19:52:53-MDT
From: William Galway <Galway@UTAH-20.ARPA>
Subject: Whoops (SETF and LAMBDAs)
To: Common-Lisp@SU-AI.ARPA
I guess I didn't make myself very clear in my previous message,
so I'll try again. First, I'm talking about two related but
distinct things, namely
1.) the lambda calculus
2.) Lisp.
I picked a rather miserable example to illustrate what I want to
do in the lambda calculus, so here's another try. The way I'd
assign a value to an expression like
((lambda (x)
(plus x 1))
2)
is to "evaluate (plus x 1) in an environment where `x' has the
value 2". What I want to do is to extend this to the case where
x isn't an atom. So to evaluate
((lambda ((sin x))
(cos x))
1)
I'd "evaluate (cos x) in an environment where the non-atomic
expression `(sin x)' has the value 1". (I'm not necessarily
claiming that "plus", "sin", "cos", "2", "1", have their typical
meanings--I suppose it depends on what they're bound to.) With
the usual meanings, I'd expect the value of the expression to be
zero, and if we plugged 0 instead of 1 into the lambda, the
result would be ambiguous, but either +1 or -1 should be valid
"interpretations".
In the case of Lisp, I was just thinking of LET as being a
convenient shorthand for LAMBDA. So
(let (
((elt v 0) (length v)))
v)
is equivalent to
((lambda ((elt v 0))
v)
(length v))
(or should that be a "(function (lambda ...))"? Anyway...)
So, is that roughly what MacLisp's "destructuring LET" did?
Something like SETF for lambdas, only without the idea that the
LET actually expanded to a lambda?
Let me also repeat that I'm not seriously suggesting
implementation of this stuff (or non-implementation for that
matter). I'm just interested in toying with the ideas (for now).
Hope that clarifies what I was trying to get across.
-- Will
-------
∂13-Oct-83 2133 JONL.PA@PARC-MAXC.ARPA SETF madness
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 13 Oct 83 21:33:01 PDT
Date: 13 OCT 83 21:25 PDT
From: JONL.PA@PARC-MAXC.ARPA
Subject: SETF madness
To: Galway@UTAH-20.ARPA
cc: Common-Lisp@SAIL.ARPA
Sometime during the 1930s or 1940s it was proven that general recursion
equtions were turing equivalent . . .
But in my lifetime, they haven't been taken too seriously as a computation
model by anyone who actually has to get work done "in real time" (Yes, PROLOG
is an exception, but I'll comment on that later. Maybe.)
What all the partially-facetious, somewhat-wishful, nearly-serious suggestions
about extending SETF are leading up to is a re-introduction of recursion
equations as a programming paradigm. To be realistic, there must be some
limit on the paradigms used. MacLisp's limit was simply that
1) variables would be bound, to
2) values obtained from CAR/CDR sequences over the input [VAX/NIL, which
I think still has some remnant of the destructing LET idea, also permits
vector-referencing in addition to CAR/CDRing.]
This led to the very-compact description of how to "spread" the computed
values of a LET into a bunch of variables: namely, a data structure whose
form was to match that of an argument, and whose symbols were the variables
to be bound. That's actually a very limited paradigm; but I stress that
those of us who used it found it most convenient.
Another serious proposal would have extended the limitation in point 1)
by including any LOCF'able place; this was coupled with a paradigm that
used a "program", rather than merely a data structure, to indicate how to
destructure the data. Thus
(LET ((`(,X ,Y) (MUMBLE))) ...)
instead of
(LET (((X Y) (MUMBLE))) ...)
That is, the "evaluable" places in the program would be places
were the destructured value would be "put". Note that
(LET (((GET 'X 'SOMEPROP) (MUMBLE))) ...) ;"Program paradigm"
would bind the result of (MUMBLE) to a spot on the property list of the
symbol X; nothing at all in the "data paradigm" can express this. In fact,
we just couldn't see how to do such binding efficiently in PDP10 MacLisp
(variables were easy -- they were built-in from antiquity), so that is one
reason we didn't try it out. On the other hand, the LispMachine apparently
is capable of binding any random cell just as easily as binding a varialbe,
so it would have made more sense to attempt it there. I believe it was
Rich Stallman's insight that this "program paradigm" was a super-set of
the "data paradigm", and could be implemented straight-forwardly; however,
I don't believe anyone ever did go to the trouble of building a prototype
and trying it out.
Now, back to the snipe at PROLOG. It is true that PROLOG as a programming
language resembles recursion equations very much, and it is also true that
there are rumors of some PROLOG implementations running "in real time".
Furthermore, I admit that some problems are very succinctly stated in
PROLOG, and their re-formulation into one of the more classic programming
languages is a "hard" problem; so it's tempting to hope that some automating
of the conversion process will make programming a lot easier. But I don't
buy it, yet. As you probe deeper into the use of PROLOG, you find that
you really can't do much without significant use of "cuts" and "directions",
which are in fact the serializers which tend to convert an apparently
descriptive program into a prescriptive one [i.e., rather than a program
which says "I would like such-and-such an efffect" into one that says
"First, do this, then do that, then do something else, then . . . "]
Except for all this madness about SETF, I'm fairly confident that the
Lisp community has it's head screwed on straight about avoiding paradigms
that trap the unwary into an exponentially-worse performance. If - - -
If Prolog really makes it big, it will have to make it possible to
express simple things like, say,
(for I from 1 to 100 sum (AREF A I))
in such a way that the loop-overhead doesn't take an order of magnitude
more time than the array referencing. SIgh, and again, if it "makes it
big", then the prolog manual will probably expand in size from a small
thin phamplet into something the size of the ZetaLisp or Interlisp tomes.
∂13-Oct-83 2155 Guy.Steele@CMU-CS-A SETF and LAMBDAs
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 13 Oct 83 21:55:21 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Oct 83 00:40:05 EDT
Date: 14 Oct 83 0050 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: William Galway <Galway@UTAH-20>
Subject: SETF and LAMBDAs
CC: common-lisp@SU-AI
In-Reply-To: "William Galway's message of 13 Oct 83 20:52-EST"
Yes, you have certainly hit upon an interesting class of ideas.
You might want to explore the literature on "declarative" and
"relational" languages, check out the PROLOG language, and perhaps
look at a couple of papers Sussman and I wrote on constraint
languages (one is in the proceedings of APL '79, and another in
the AI Journal a couple of years ago). These all have some related
notions, though not exactly what you have suggested. You might
ponder the notions that your idea requires (1) a general method
for inverting functions calls to which appear as lambda parameters,
and (2) some means of dealing with multiple solutions when the
inverses turn out to be one-many relations.
--Guy
∂14-Oct-83 1141 RPG Insane
∂11-Oct-83 0928 FAHLMAN@CMU-CS-C.ARPA Insane
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Oct 83 09:27:26 PDT
Received: ID <VAF@CMU-CS-C.ARPA>; Tue 11 Oct 83 12:05:36-EDT
Date: Sun, 9 Oct 1983 16:54 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moo%CRC@MIT-MC.ARPA>
Cc: bs%CRC@MIT-MC.ARPA, dl%CRC@MIT-MC.ARPA, Guy.Steel@CMU-CS-A.ARPA
rp@λSU-AI@λ fahlman@CMU-CS-C.ARPA
Subject: Insane
In-reply-to: Msg of 9 Oct 1983 15:35-EDT from David A. Moon <Moon at SCRC at mit-mc>
The proposal to drop #+ and #- from the white pages is indeed insane if
you view these as mechanisms for porting code among Common Lisp
implementations. It makes sense if you view these macros as being only
for the purpose of more easily inheriting code from earlier non-Common
Lisps. In that case, these things could well be part of the Zetalisp
compatibility package, or whatever. And, of course, compatibility with
earlier Lisps is the only possible reason for retaining the
brain-damaged syntax of #+ and #-.
Moon is persuasive in his argument that we ought to have some sort of
conditional reading facility in the white pages for sharing among
slightly different versions of Common Lisp. The most common need for
this will be in the area of differing floating-point formats, but there
will probably be other places. I now agree that we must provide such a
facility. If it's worth doing this, it's worth doing it right.
My proposed #U and #W are extremely simple, extremely easy to implement,
and extremely easy to explain, and they do the right thing in all cases.
These benefits come from the fact that the alien stuff never gets near
the reader, except as uninterpreted characters in the guts of a string.
Now that Moon has convincingly made the argument that Common Lisp needs
such a facility in the white pages, I think it should be this one. (I
would, of course, be happy to rename these to #+ and #- if people can
live with that.)
Moon is wrong in stating that #+ and #- are "extremely simple, extremely
easy to implement, and rather easy to explain." He can't have all of
those at once. The traditional #+ and #- macros, which just call READ
on the uninterpreted object, are easy to implement but would cause
errors in many of the cases of interest, including flonums and
non-standard character objects. If we put in all the suppress-p
exceptions that he wants, it is hard to implement and hard to explain
properly, since all of the cases must be enumerated. If we offer the
simple explanation that these forms conditionally read a lisp object and
discard the result, without causing any side effects or signaling
errors, it is impossible to implement #+ and #- correctly with the old
undelimited syntax.
I am strongly in favor of putting something with the syntax of #U and #W
into the white pages, whatever characters we assign these things to. If
people really want to include the nearly-worthless simple forms of #+
and #- (just READ normally and discard the result), I can go along with
that as well. I am still unwilling to do a lot of work to patch up our
reader to make #+ and #- work better.
-- Scott
∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
∂11-Oct-83 2103 Guy.Steele@CMU-CS-A #+ and Bob and #W and Alice
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 11 Oct 83 21:03:28 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 11 Oct 83 23:52:27 EDT
Date: 12 Oct 83 0002 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>
Subject: #+ and Bob and #W and Alice
CC: rpg@SU-AI, bsg%scrc-tenex@MIT-ML, moon%scrc-tenex@MIT-ML,
dlw%scrc-tenex@MIT-ML
Actually, #+ suffices:
#+LISPM #,(read-from-stri#+LISPM "#C(xiv viii)" #-LISPM "()")
instead of
#WLISPM "#C(xiv viii)"
Admittedly it's a bit verbose.
I think I am somewhat more persuaded by Scott's arguments now. Putting
double quotes around what (as Moon says) ought to be fairly short pieces
of code doesn't seem so bad.
I don't think positive and negative forms are all that necessary;
why can't we just write (not lispm) ? I would suggest "#?" except
that we have reserved that to the user. Therefore I propose "#@"
as a new name for "#W".
(setq x #@SPICE "1.0L1500"
#@(AND (NOT SPICE) LISPM) "#\Hyper-Space"
#@(AND (NOT SPICE) (NOT LISPM) EBCDIC) "#x40"
#@(AND (NOT SPICE) (NOT LISPM) (NOT EBCDIC)) "#o40"
)
However, I don't feel warranted in putting in this syntax as a language
change unless everyone can give it at least grudging support.
--Guy
∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
∂11-Oct-83 2132 @MIT-MC:Moon%SCRC-TENEX@MIT-MC #+ and Bob and #W and Alice
Received: from MIT-MC by SU-AI with TCP/SMTP; 11 Oct 83 21:32:33 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 12-Oct-83 00:24:48-EDT
Date: Wednesday, 12 October 1983, 00:32-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-MC>
Subject: #+ and Bob and #W and Alice
To: Guy.Steele@CMU-CS-A
Cc: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, bsg%SCRC-TENEX@MIT-MC,
dlw%SCRC-TENEX@MIT-MC
In-reply-to: The message of 12 Oct 83 00:02-EDT from Guy.Steele at CMU-CS-A
Date: 12 Oct 83 0002 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
I think I am somewhat more persuaded by Scott's arguments now. Putting
double quotes around what (as Moon says) ought to be fairly short pieces
of code doesn't seem so bad.
#+ is frequently used in front of entire function definitions. Thus you quickly
get into the infinitely deep morass of re-quoting quoted strings. Ask anyone
who has written exec←com command procedures on Multics. The more of this
discussion I read the more I think the present #+ is more well-thought-out than
I thought originally.
By the way, what's so great about using double-quotes for grouping? Isn't
this Lisp, where we customarily use parentheses for grouping?
∂14-Oct-83 1141 RPG #+ and Bob and #W and Alice
∂12-Oct-83 0637 @MIT-MC:BSG%SCRC-TENEX@MIT-MC #+ and Bob and #W and Alice
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Oct 83 06:36:59 PDT
Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Wed 12-Oct-83 09:40:13-EDT
Date: Wednesday, 12 October 1983, 09:38-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-MC>
Subject: #+ and Bob and #W and Alice
To: Guy.Steele@CMU-CS-A, FAHLMAN@CMU-CS-C
Cc: rpg@SU-AI, moon%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC
In-reply-to: The message of 12 Oct 83 00:02-EDT from Guy.Steele at CMU-CS-A
Date: 12 Oct 83 0002 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
I think I am somewhat more persuaded by Scott's arguments now. Putting
double quotes around what (as Moon says) ought to be fairly short pieces
of code doesn't seem so bad.
(setq x #@SPICE "1.0L1500"
#@(AND (NOT SPICE) LISPM) "#\Hyper-Space"
Hey, great advocate of the triviality and the simplicity of the
syntax, you forgot to double the backslash.
I think this speaks against it.
#@(AND (NOT SPICE) (NOT LISPM) EBCDIC) "#x40"
#@(AND (NOT SPICE) (NOT LISPM) (NOT EBCDIC)) "#o40"
)
∂14-Oct-83 1142 RPG SETF and Prolog
∂12-Oct-83 0642 Meehan@YALE SETF and Prolog
Received: from YALE by SU-AI with TCP/SMTP; 12 Oct 83 06:42:04 PDT
Received: by YALE-BULLDOG via CHAOS; Wed, 12 Oct 83 09:45:40 EDT
Date: Wed, 12 Oct 83 09:39:39 EDT
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: SETF and Prolog
To: common-lisp@SU-AI.ARPA
As long as you're doing (SETF (+ X 3) 10), why not use SETF as a
notation for Prolog-style assertions? E.g.,
(SETF (GRANDFATHER-OF X) 'THOMAS).
(-: There. We embedded it again. :-)
-------
∂14-Oct-83 1143 RPG #+ and Bob and #W and Alice
∂12-Oct-83 1015 @MIT-MC:DLW%SCRC-TENEX@MIT-MC #+ and Bob and #W and Alice
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Oct 83 10:15:17 PDT
Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Wed 12-Oct-83 13:17:56-EDT
Date: Wednesday, 12 October 1983, 13:13-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: #+ and Bob and #W and Alice
To: Moon%SCRC-TENEX@MIT-MC, Guy.Steele@CMU-CS-A
Cc: FAHLMAN@CMU-CS-C, rpg@SU-AI, bsg%SCRC-TENEX@MIT-MC
In-reply-to: The message of 12 Oct 83 00:32-EDT from David A. Moon <Moon at SCRC-TENEX>
Hi. I've been out of town and just caught up with my mail. I'm
reasonably happy with the discussion and the way decisions went. The
decision about vertical bars in package names and use of :: is OK with
me. I'm also in favor of keeping MACROLET as GLS recommended and Moon
further justified. I agree fully with Moon about the portability of
Newline question; Moon and I have discussed this extensively in the
past. On all the other issues besides #+, I agree with the concensus
on all those issues that I know/care about.
Regarding #+, I agree completely with what Moon and BSG have already
said. It would be ludicrous to flush the feature; it's very important.
I do NOT want to get into re-quoting issues; I have seen the evil that
this leads to and really don't want to get us involved in that. The
feature to suppress errors is quite simple to explain and implement and
saves a lot of trouble. The various hairy proposals do not particularly
appeal to me; let's keep it simple.
∂14-Oct-83 1143 RPG #+ and Bob and #W and Alice
∂12-Oct-83 1028 FAHLMAN@CMU-CS-C.ARPA #+ and Bob and #W and Alice
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Oct 83 10:28:31 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 12 Oct 83 13:29:53-EDT
Date: Wed, 12 Oct 1983 13:29 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC.ARPA>
Cc: bsg%SCRC-TENEX@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA,
Moon%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: #+ and Bob and #W and Alice
In-reply-to: Msg of 12 Oct 1983 13:13-EDT from Daniel L. Weinreb <DLW%SCRC-TENEX at MIT-MC>
Looks like everything is settled now. Can this really be????
-- Scott
∂14-Oct-83 1143 RPG Re: SETF and Prolog
∂12-Oct-83 1056 LES@CMU-CS-C.ARPA Re: SETF and Prolog
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Oct 83 10:52:54 PDT
Received: ID <LES@CMU-CS-C.ARPA>; Wed 12 Oct 83 13:54:38-EDT
Date: Wed 12 Oct 83 13:54:37-EDT
From: LES@CMU-CS-C.ARPA
Subject: Re: SETF and Prolog
To: Meehan@YALE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Jim Meehan <Meehan@YALE.ARPA>" of Wed 12 Oct 83 09:50:24-EDT
Assuming that x has the structure of a person, i.e. that you use a defstruct
to define what a person is, then the setf form for the grandfather field
is well defined. Something like:
(defstruct person (:conc-name nil ...)
.
.
(grandfather-of nil)
.
.
)
Will make the supplied setf form entirely valid.
-Lee
-------
∂14-Oct-83 1144 RPG #+/#-
∂12-Oct-83 1408 @MIT-MC:BSG@SCRC-TENEX #+/#-
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Oct 83 14:08:29 PDT
Received: from scrc-beagle by scrc-vixen with CHAOS; 11 Oct 1983 15:20:53-EDT
Date: Tuesday, 11 October 1983, 15:24-EDT
From: Bernard S. Greenberg <BSG at SCRC at mit-mc>
Subject: #+/#-
To: Fahlman at CMU-CS-C at mit-mc, Moon at SCRC at mit-mc
Cc: dlw at SCRC at mit-mc, rpg at SU-AI at mit-mc, STEELE at CMU-CS-C at mit-mc
In-reply-to: The message of 8 Oct 83 16:27-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Look, do you think that anyone is going to believe
#W(whatever)
"(if (string-search-char #\\: (fs:default-mumble \"FOO\"))..."
God forbid you tried to nest them? Putting something in a #W
causes miniscule, pervasive text modifications in the code conditionalized,
which are neither easy to read, understand, add or remove.
For this reason, #; has it all over #W.
But don't get me wrong, my votes are all cast for #+ #-, whatever kludgery
is needed in implementation.
∂14-Oct-83 1144 RPG Ted and #U and Carol and #-
∂12-Oct-83 2011 Guy.Steele@CMU-CS-A Ted and #U and Carol and #-
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 12 Oct 83 20:11:14 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 12 Oct 83 23:00:56 EDT
Date: 12 Oct 83 2310 EDT (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, bsg%scrc-tenex@MIT-ML,
moon%scrc-tenex@MIT-ML, dlw%scrc-tenex@MIT-ML
Subject: Ted and #U and Carol and #-
I hereby declare the #+/#- issue settled. It will remain as described,
with the various suppression features described by myself and Moon.
To my knowledge, then, the only outstanding point is this issue of LET*
and SETF. I await eagerly the exposition from the Symbolics folks.
--Guy
∂14-Oct-83 1145 RPG SETF and LAMBDAs (semi-serious?)
∂13-Oct-83 1051 GALWAY@UTAH-20.ARPA SETF and LAMBDAs (semi-serious?)
Received: from UTAH-20 by SU-AI with TCP/SMTP; 13 Oct 83 10:51:37 PDT
Date: Thu 13 Oct 83 11:53:06-MDT
From: William Galway <Galway@UTAH-20.ARPA>
Subject: SETF and LAMBDAs (semi-serious?)
To: Common-Lisp@SU-AI.ARPA
All this discussion about the power of SETF has reminded me of an
idea that I've been toying with for awhile. Basically, I'd like
to modify the lambda calculus to allow non-atomic "arguments" for
the lambda. So, in addition to things like:
(lambda (x)
(lambda (y)
x))
(the K combinator, I think), it would also be legitimate to have
things like:
(lambda (x)
((lambda ((y x)) (y x))
x))
(which I think would be the identity function).
I don't claim that there's any good reason for doing this--it just seemed
like a natural thing to do during one of my weirder moments. If anyone
knows if work has already been done with this funny variant of the lambda
calculus, I'd be interested in hearing about it.
On the other hand, if we leave the world of pure mathematical systems and
enter the world of Lisp, it does kind of appeal to me to be able to write
code like:
(let (
((elt v 0) (length v)))
v)
but, I'm not seriously suggesting that it be implemented...
-- Will Galway
-------
∂14-Oct-83 1145 RPG SETF and LAMBDAs (semi-serious?)
∂13-Oct-83 1232 @MIT-MC:MOON@SCRC-TENEX SETF and LAMBDAs (semi-serious?)
Received: from MIT-MC by SU-AI with TCP/SMTP; 13 Oct 83 12:32:01 PDT
Date: Thursday, 13 October 1983 14:39-EDT
From: MOON at SCRC-TENEX
To: William Galway <Galway at UTAH-20.ARPA>
Cc: Common-Lisp at SU-AI.ARPA
Subject: SETF and LAMBDAs (semi-serious?)
In-reply-to: The message of Thu 13 Oct 83 11:53:06-MDT from William Galway <Galway@UTAH-20.ARPA>
This was implemented in Maclisp under the name of "destructuring LET".
It raises a number of complicated issues that I don't think we should get
involved in right now. Note, as just one example, that you were not
consistent with yourself in the examples you give of what it might do.
Your first example
(lambda (x)
((lambda ((y x)) (y x))
x))
seems to expect the argument to be a list of two elements, where y
is bound to the first element and x is bound to the second. In other
words the "pattern" in the lambda-expression is a piece of data acting
as a template. Unless I misunderstand the example completely, which
is possible since it certainly isn't written in Common Lisp.
In your second example,
(let (
((elt v 0) (length v)))
v)
the "pattern" in the lambda-expression (a let this time) is a piece of
code describing a location to be stored into. I won't even go into the
deeper semantic issues raised by your second example; the syntactic
issues are enough to show that it is complicated.
Note that if you add a new special form (a macro) to the language,
rather than redefining existing things such as let and lambda, you
can experiment with various versions of such things in any Common Lisp
implementation, or any other reasonable Lisp implementation, without
any need to change the compiler, interpreter, or run-time.
∂14-Oct-83 1146 RPG Whoops (SETF and LAMBDAs)
∂13-Oct-83 1851 GALWAY@UTAH-20.ARPA Whoops (SETF and LAMBDAs)
Received: from UTAH-20 by SU-AI with TCP/SMTP; 13 Oct 83 18:51:18 PDT
Date: Thu 13 Oct 83 19:52:53-MDT
From: William Galway <Galway@UTAH-20.ARPA>
Subject: Whoops (SETF and LAMBDAs)
To: Common-Lisp@SU-AI.ARPA
I guess I didn't make myself very clear in my previous message,
so I'll try again. First, I'm talking about two related but
distinct things, namely
1.) the lambda calculus
2.) Lisp.
I picked a rather miserable example to illustrate what I want to
do in the lambda calculus, so here's another try. The way I'd
assign a value to an expression like
((lambda (x)
(plus x 1))
2)
is to "evaluate (plus x 1) in an environment where `x' has the
value 2". What I want to do is to extend this to the case where
x isn't an atom. So to evaluate
((lambda ((sin x))
(cos x))
1)
I'd "evaluate (cos x) in an environment where the non-atomic
expression `(sin x)' has the value 1". (I'm not necessarily
claiming that "plus", "sin", "cos", "2", "1", have their typical
meanings--I suppose it depends on what they're bound to.) With
the usual meanings, I'd expect the value of the expression to be
zero, and if we plugged 0 instead of 1 into the lambda, the
result would be ambiguous, but either +1 or -1 should be valid
"interpretations".
In the case of Lisp, I was just thinking of LET as being a
convenient shorthand for LAMBDA. So
(let (
((elt v 0) (length v)))
v)
is equivalent to
((lambda ((elt v 0))
v)
(length v))
(or should that be a "(function (lambda ...))"? Anyway...)
So, is that roughly what MacLisp's "destructuring LET" did?
Something like SETF for lambdas, only without the idea that the
LET actually expanded to a lambda?
Let me also repeat that I'm not seriously suggesting
implementation of this stuff (or non-implementation for that
matter). I'm just interested in toying with the ideas (for now).
Hope that clarifies what I was trying to get across.
-- Will
-------
∂14-Oct-83 1146 RPG SETF madness
∂13-Oct-83 2133 JONL.PA@PARC-MAXC.ARPA SETF madness
Received: from PARC-MAXC by SU-AI with TCP/SMTP; 13 Oct 83 21:33:01 PDT
Date: 13 OCT 83 21:25 PDT
From: JONL.PA@PARC-MAXC.ARPA
Subject: SETF madness
To: Galway@UTAH-20.ARPA
cc: Common-Lisp@SAIL.ARPA
Sometime during the 1930s or 1940s it was proven that general recursion
equtions were turing equivalent . . .
But in my lifetime, they haven't been taken too seriously as a computation
model by anyone who actually has to get work done "in real time" (Yes, PROLOG
is an exception, but I'll comment on that later. Maybe.)
What all the partially-facetious, somewhat-wishful, nearly-serious suggestions
about extending SETF are leading up to is a re-introduction of recursion
equations as a programming paradigm. To be realistic, there must be some
limit on the paradigms used. MacLisp's limit was simply that
1) variables would be bound, to
2) values obtained from CAR/CDR sequences over the input [VAX/NIL, which
I think still has some remnant of the destructing LET idea, also permits
vector-referencing in addition to CAR/CDRing.]
This led to the very-compact description of how to "spread" the computed
values of a LET into a bunch of variables: namely, a data structure whose
form was to match that of an argument, and whose symbols were the variables
to be bound. That's actually a very limited paradigm; but I stress that
those of us who used it found it most convenient.
Another serious proposal would have extended the limitation in point 1)
by including any LOCF'able place; this was coupled with a paradigm that
used a "program", rather than merely a data structure, to indicate how to
destructure the data. Thus
(LET ((`(,X ,Y) (MUMBLE))) ...)
instead of
(LET (((X Y) (MUMBLE))) ...)
That is, the "evaluable" places in the program would be places
were the destructured value would be "put". Note that
(LET (((GET 'X 'SOMEPROP) (MUMBLE))) ...) ;"Program paradigm"
would bind the result of (MUMBLE) to a spot on the property list of the
symbol X; nothing at all in the "data paradigm" can express this. In fact,
we just couldn't see how to do such binding efficiently in PDP10 MacLisp
(variables were easy -- they were built-in from antiquity), so that is one
reason we didn't try it out. On the other hand, the LispMachine apparently
is capable of binding any random cell just as easily as binding a varialbe,
so it would have made more sense to attempt it there. I believe it was
Rich Stallman's insight that this "program paradigm" was a super-set of
the "data paradigm", and could be implemented straight-forwardly; however,
I don't believe anyone ever did go to the trouble of building a prototype
and trying it out.
Now, back to the snipe at PROLOG. It is true that PROLOG as a programming
language resembles recursion equations very much, and it is also true that
there are rumors of some PROLOG implementations running "in real time".
Furthermore, I admit that some problems are very succinctly stated in
PROLOG, and their re-formulation into one of the more classic programming
languages is a "hard" problem; so it's tempting to hope that some automating
of the conversion process will make programming a lot easier. But I don't
buy it, yet. As you probe deeper into the use of PROLOG, you find that
you really can't do much without significant use of "cuts" and "directions",
which are in fact the serializers which tend to convert an apparently
descriptive program into a prescriptive one [i.e., rather than a program
which says "I would like such-and-such an efffect" into one that says
"First, do this, then do that, then do something else, then . . . "]
Except for all this madness about SETF, I'm fairly confident that the
Lisp community has it's head screwed on straight about avoiding paradigms
that trap the unwary into an exponentially-worse performance. If - - -
If Prolog really makes it big, it will have to make it possible to
express simple things like, say,
(for I from 1 to 100 sum (AREF A I))
in such a way that the loop-overhead doesn't take an order of magnitude
more time than the array referencing. SIgh, and again, if it "makes it
big", then the prolog manual will probably expand in size from a small
thin phamplet into something the size of the ZetaLisp or Interlisp tomes.
∂14-Oct-83 1147 RPG SETF and LAMBDAs
∂13-Oct-83 2155 Guy.Steele@CMU-CS-A SETF and LAMBDAs
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 13 Oct 83 21:55:21 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Oct 83 00:40:05 EDT
Date: 14 Oct 83 0050 EDT (Friday)
From: Guy.Steele@CMU-CS-A
To: William Galway <Galway@UTAH-20>
Subject: SETF and LAMBDAs
CC: common-lisp@SU-AI
In-Reply-To: "William Galway's message of 13 Oct 83 20:52-EST"
Yes, you have certainly hit upon an interesting class of ideas.
You might want to explore the literature on "declarative" and
"relational" languages, check out the PROLOG language, and perhaps
look at a couple of papers Sussman and I wrote on constraint
languages (one is in the proceedings of APL '79, and another in
the AI Journal a couple of years ago). These all have some related
notions, though not exactly what you have suggested. You might
ponder the notions that your idea requires (1) a general method
for inverting functions calls to which appear as lambda parameters,
and (2) some means of dealing with multiple solutions when the
inverses turn out to be one-many relations.
--Guy
∂20-Oct-83 1710 AS%HP-HULK.HP-Labs@Rand-Relay character names
Received: from RAND-RELAY by SU-AI with TCP/SMTP; 20 Oct 83 17:10:12 PDT
Date: 20 Oct 1983 1341-PDT
From: AS.HP-HULK@Rand-Relay
Return-Path: <AS%HP-HULK.HP-Labs@Rand-Relay>
Subject: character names
Received: by HP-VENUS via CHAOSNET; 20 Oct 1983 13:43:08-PDT
To: Common-Lisp@SU-AI
Cc: AS%AS.HP-LABS@Rand-Relay
Message-Id: <435530590.19147.hplabs@HP-VENUS>
Via: HP-Labs; 20 Oct 83 15:07-PDT
I could not find the answers to these questions in the Excelsior edition: In
which package do the character name symbols returned by the function CHAR-NAME
reside? [I would guess the Lisp package.] How does the function NAME-CHAR
compare its argument to the known character-name symbols? Does it use EQ or
does it examine the print-name and do something fancy like #\ (treat a single
character print-name case-sensitively, but treat a longer print-name
case-insensitively). [I would guess the latter.]
-------
∂25-Oct-83 0820 RPG Need advice on token scanning in Common LISP
∂24-Oct-83 0012 Guy.Steele@CMU-CS-A Need advice on token scanning in Common LISP
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 24 Oct 83 00:12:33 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 24 Oct 83 03:01:11 EDT
Date: 24 Oct 83 0302 EDT (Monday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, rms%oz@MIT-ML,
moon%scrc-tenex@MIT-ML, dlw%scrc-tenex@MIT-ML, bsg%scrc-tenex@MIT-ML
Subject: Need advice on token scanning in Common LISP
I foresee problems in making future extensions to Common LISP unless we
make provisions now. I will make *none* of these changes, except the
one that fixes an ambiguity, unless most of you agree to them, and soon.
The ambiguity is that when *read-base* is 16, for example, 1E0 can be
interpreted as a a hexidecimal number *and* as a floating-point number.
The extensibility issues are in the treatment of tokens. Right now, the
specification is "anything that doesn't look like a number is a symbol".
This can be misleading, and doesn't leave much room for extensions. For
example, "5R0" and "5J0" are required to be treated as symbols, whereas
"5S0" and "5L0" are floating-point numbers. The implementation that
wishes to experiment with a notation for complex numbers such as "5+3J"
is also out of luck.
I have several relatively orthogonal proposals:
(1) When a letter could be interpreted as both a digit (because
*read-base* is larger than 10 and the token contains no decimal point)
and as a floating-point exponent marker, it shall be interpreted as a
digit. (I will make this clarification unless someone provides a better
resolution.)
(2) Make all letters be valid floating-point exponent markers (most of
them being reserved for future use). (Item (3) subsumes this proposal
in a more general way.)
(3) Any token satisfying the following description and not fitting the
syntax of a Common LISP number is not a symbol, but is reserved for
extensions; for each such token every implementation must either
provide an interpretation as a LISP object or else signal an error.
Consists entirely of digits, plus or minus signs (+ and -), ratio
markers (/), decimal points (.), the extension characters "↑" and "←",
and number markers (a letter may be interpreted as a number marker
only if not preceded or followed by another letter). No character
whose interpretation must be alphabetic is permitted. A letter is
treated as alphabetic if it cannot be treated as a digit or number
marker.
Begins with a digit, sign, decimal point, or "↑" or "←".
Contains at least one digit (very important). Letters may be
considered to be digits, depending on *read-base*, but only in tokens
containing no decimal points.
Does not end with a sign (this legitimizes 1+ and 1-).
(4) Tokens containing the character "%" are specifically reserved to
the implementor and are not portable.
(5) For robustness, make the whitespace and rubout characters in table 22-3
(Excelsior page 270) have the attribute "illegal" instead of "alphabetic".
This move is purely for robustness: even if someone is idiotic enough
to try to make them be constituents instead of whitespace (or whatever),
it is still necessary to use escape chaarcters to get them into tokens.
--Guy
∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
∂24-Oct-83 0843 FAHLMAN@CMU-CS-C.ARPA Need advice on token scanning in Common LISP
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 24 Oct 83 08:43:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Oct 83 11:46:46-EDT
Date: Mon, 24 Oct 1983 11:46 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
moon%scrc-tenex@MIT-ML.ARPA, rms%oz@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Need advice on token scanning in Common LISP
In-reply-to: Msg of 24 Oct 83 0302 EDT () from Guy.Steele at CMU-CS-A
Regarding the ambiguity Guy points out, I'd like to keep this simple.
Remember that we allowed *READ-BASE* to crawl back into the language
only so that it could be used in reading data files and to aid in
importing old code from the brain-damged octal Lisps, not for use in
poartable code. With respect to supra-decimal bases, only the former
use comes up. So it would not bother me too much to restrict the
freedom of expression of those people who set *READ-BASE* to something
greater than 10. Remember too that it was a rather close decision about
whether 1E6 should be a legal flonum. Let me propose the following way
to resolve the abiguity:
In general, floating point numbers must have a decimal point embedded in
them somewhere (not at the end). For user convenience, if *read-base*
is ten or less, the decimal point may be omitted and a flonum may be
indicated by any one of the built-in exponent markers: s, f, d, l, b (or
the upper case versions thereof). If *read-base* is > 10., the decimal
point is required, else the number is interpreted as an integer or symbol,
depending on whether it is a legal integer in the specified radix.
If people don't like that, I could live with Guy's simple solution 1: if
you can't tell if something is a digit or exponent, it's a digit. Might
be a bit hairy to implement -- I haven't thought through all the cases
yet -- but it's unambiguous.
(4) Tokens containing the character "%" are specifically reserved to
the implementor and are not portable.
In fact, both the CMU-derived Common Lisp implementations and Lispm use
% as a "don't tread on me" character in function and variable names, so
maybe we should make it official. However, there seem to be a bunch of
people who automatically object to any attempt to remove classes of
names from the legal name space, and the right long-run solution is to
do this with packages, so maybe we shouldn't make this official.
Guy's proposed change to the handling of whitespace characters looks OK
to me, though I haven't felt the need to save users from this particular
form of insanity. I abstain on point 5.
-- Scott
∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
∂24-Oct-83 1020 @MIT-ML:Moon%SCRC-TENEX@MIT-ML Need advice on token scanning in Common LISP
Received: from MIT-ML by SU-AI with TCP/SMTP; 24 Oct 83 10:19:48 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 24-Oct-83 13:17:03-EDT
Date: Monday, 24 October 1983, 13:15-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-ML>
Subject: Need advice on token scanning in Common LISP
To: Guy.Steele@CMU-CS-A, Scott E. Fahlman <Fahlman@CMU-CS-C>
Cc: rpg@SU-AI, rms%oz@MIT-ML, moon%scrc-tenex@MIT-ML, dlw%scrc-tenex@MIT-ML,
bsg%scrc-tenex@MIT-ML
In-reply-to: The message of 24 Oct 83 03:02-EDT from Guy.Steele at CMU-CS-A,
The message of 24 Oct 83 11:46-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: 24 Oct 83 0302 EDT (Monday)
From: Guy.Steele@CMU-CS-A
The ambiguity is that when *read-base* is 16, for example, 1E0 can be
interpreted as a a hexidecimal number *and* as a floating-point number.
(1) When a letter could be interpreted as both a digit (because
*read-base* is larger than 10 and the token contains no decimal point)
and as a floating-point exponent marker, it shall be interpreted as a
digit. (I will make this clarification unless someone provides a better
resolution.)
This is right. We should definitely say this in the manual. A
higher-level way of saying the same thing is that if a token could be
interpreted as either a floating-point number or an integer, it is
always interpreted as an integer. (This rule is already enforced by the
slight contortions in the BNF (Excelsior page 268) to make the syntax
for floating-point number exclude the uses of decimal points in
integers.)
The extensibility issues are in the treatment of tokens. Right now, the
specification is "anything that doesn't look like a number is a symbol".
This can be misleading, and doesn't leave much room for extensions. For
example, "5R0" and "5J0" are required to be treated as symbols, whereas
"5S0" and "5L0" are floating-point numbers. The implementation that
wishes to experiment with a notation for complex numbers such as "5+3J"
is also out of luck.
(2) Make all letters be valid floating-point exponent markers (most of
them being reserved for future use). (Item (3) subsumes this proposal
in a more general way.)
(3) Any token satisfying the following description and not fitting the
syntax of a Common LISP number is not a symbol, but is reserved for
extensions; for each such token every implementation must either
provide an interpretation as a LISP object or else signal an error.
What else could they do but provide an interpretation as a Lisp object or
signal an error? Or do you mean that the Lisp object is required to
be something other than a symbol?
Consists entirely of digits, plus or minus signs (+ and -), ratio
markers (/), decimal points (.), the extension characters "↑" and "←",
It seems odd to special-case ↑ and ← since Common Lisp does not have them.
Maclisp has them but what if somebody decides they want to use < and > as
extension characters in numbers?
and number markers (a letter may be interpreted as a number marker
only if not preceded or followed by another letter). No character
whose interpretation must be alphabetic is permitted. A letter is
treated as alphabetic if it cannot be treated as a digit or number
marker.
Begins with a digit, sign, decimal point, or "↑" or "←".
Contains at least one digit (very important). Letters may be
considered to be digits, depending on *read-base*, but only in tokens
containing no decimal points.
Does not end with a sign (this legitimizes 1+ and 1-).
This is okay with me provided that an implementation is allowed to interpret
these tokens as symbols. In that case what we are specifying is simply that
there is a certain class of tokens that may not be used in portable programs,
because different implementations will interpret them differently. Elsewhere
in the Common Lisp manual the phrase "is an error" is sometimes used to mean
this, i.e. "is an implementation-dependent extension or an error".
(4) Tokens containing the character "%" are specifically reserved to
the implementor and are not portable.
The use of %'s in the Lisp machine is merely a holdover from the days before
there were packages. I don't think this anomaly should be enshrined in
Common Lisp. Whether or not an implementation uses such a convention internally,
these symbols should not be in the LISP package. USE-PACKAGE can be used to
get them in places where they are wanted.
(5) For robustness, make the whitespace and rubout characters in table 22-3
(Excelsior page 270) have the attribute "illegal" instead of "alphabetic".
This move is purely for robustness: even if someone is idiotic enough
to try to make them be constituents instead of whitespace (or whatever),
it is still necessary to use escape chaarcters to get them into tokens.
I don't care about this one either way.
Date: Mon, 24 Oct 1983 11:46 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Regarding the ambiguity Guy points out, I'd like to keep this simple....
I think Guy's proposal is simpler than Scott's proposal.
Possibly also relevant to this discussion is the solution we adopted a while back
to the *READ-BASE* > 10 problem. We provide the following two variables:
;;; Handling of tokens that can be symbols, floating-point numbers, or integers in
;;; bases greater than ten.
;;; The following flags are global modes that control what happens when
;;; IBASE is greater than ten. Certain tokens made up of digits and letters
;;; could be interpreted either as integers or as symbols (or in some cases
;;; floating-point numbers).
;;; The initial values given here are compatible with both Zetalisp and Common Lisp.
******* actually Common Lisp seems to have changed its mind since
******* the above comment was written. The bottom of Excelsior 268
******* indicates that both variables would be T.
(DEFVAR *READ-EXTENDED-IBASE-UNSIGNED-NUMBER* ':SINGLE
"Controls how a token that could be a number or a symbol, and does not start
with a + or - sign, is interpreted when IBASE is greater than ten.
NIL => it is never a number.
T => it is always a number.
:SHARPSIGN => it is a symbol at top level, but a number after #X or #nR.
:SINGLE => it is a symbol except immediately after #X or #nR.")
(DEFVAR *READ-EXTENDED-IBASE-SIGNED-NUMBER* ':SHARPSIGN ;"White's Hack"
"Controls how a token that could be a number or a symbol, and starts
with a + or - sign, is interpreted when IBASE is greater than ten.
NIL => it is never a number.
T => it is always a number.
:SHARPSIGN => it is a symbol at top level, but a number after #X or #nR.
:SINGLE => it is a symbol except immediately after #X or #nR.")
∂25-Oct-83 0822 RPG Need advice on token scanning in Common LISP
∂24-Oct-83 1912 FAHLMAN@CMU-CS-C.ARPA Need advice on token scanning in Common LISP
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 24 Oct 83 19:12:23 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Oct 83 22:15:16-EDT
Date: Mon, 24 Oct 1983 22:15 EDT
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: David A. Moon <Moon%SCRC-TENEX@MIT-ML.ARPA>
Cc: bsg%scrc-tenex@MIT-ML.ARPA, dlw%scrc-tenex@MIT-ML.ARPA,
Guy.Steele@CMU-CS-A.ARPA, rms%oz@MIT-ML.ARPA, rpg@SU-AI.ARPA
Subject: Need advice on token scanning in Common LISP
In-reply-to: Msg of 24 Oct 1983 13:15-EDT from David A. Moon <Moon%SCRC-TENEX at MIT-ML>
I guess that given Moon's rephrasing (if a token could be either a
floating-point number or an integer, it's an integer), I agree that
Guy's solution is simpler than mine. Let's go with that. And let's not
mess with reserving tokens with % in them.
-- Scott
∂25-Oct-83 0823 RPG RMS replies to 15 hairy issues
∂25-Oct-83 0758 Guy.Steele@CMU-CS-A RMS replies to 15 hairy issues
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 25 Oct 83 07:57:19 PDT
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 25 Oct 83 10:44:33 EDT
Date: 25 Oct 83 1052 EDT (Tuesday)
From: Guy.Steele@CMU-CS-A
To: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, moon%scrc-tenex@MIT-ML,
dlw%scrc-tenex@MIT-ML, bsg%scrc-tenex@MIT-ML
Subject: RMS replies to 15 hairy issues
- - - - Begin forwarded message - - - -
Received: from CMU-CS-PT by CMU-CS-A; 11 Oct 83 05:37:16 EDT
Received: from CMU-CS-C by CMU-CS-PT; 11 Oct 83 05:26:08 EDT
Received: from MIT-ML by CMU-CS-C with TCP; Tue 11 Oct 83 05:36:16-EDT
Date: Tue 11 Oct 83 03:47:35-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: Nasty Common LISP Issues
To: STEELE@CMU-CS-C.ARPA
In-Reply-To: Message from "STEELE@CMU-CS-C.ARPA" of Sat 8 Oct 83 01:14:34-EDT
1. I agree with you about MACROLET bodies.
2. I have already gone to trouble to convert the reader to fit
the last version of the manual. This change is neither the old
way I had it nor the new way, therefore means more hassles changing
reader and readtable together. Ugh.
3. I have told the users that "::" prefixes refer to "shadowed"
package names. Common Lisp does not have local nicknames that
can override global names for packages, but I do, and I also need
a way to override them (refer only to global names).
I suppose I could swap the meanings of #: and ::, but then I am
no better off than now (I still have to be using #: for something)
and it does mean a hassle. (I also use the combination #::).
So I'm somewhat opposed to changes 2 and 3.
4. You speak as if you were passing on what I said about RECURSIVE-P,
but you have changed it. What I propose is that RECURSIVE-P should
have no effect on the handling of end-of-file. That should be controlled
only by EOF-ERRORP and EOF-VALUE. Recursive calls to READ can simply
pass T for EOF-ERRORP. This is simpler to describe, and also eliminates
the need for any hair to pass along the outer values of EOF-ERRORP and
EOF-VALUE. This is never done, in my proposed scheme.
What advantage is there in passing along the top-level value of EOF-ERRORP
and never looking at it?
Meanwhile, what is the use of the RECURSIVE-P argument in READ-LINE,
READ-CHAR and PEEK-CHAR? Have you decided to flush it?
5. I have fixed this #+ problem approximately as you have said,
so I approve. I did it using a special variable which is non-NIL
when within failing conditionals. This is a much better way to
allow user readmacros to test for that situation, since it does not
require a wholesale change to their calling sequence. I would not
mind adding a new name to this special variable. *READ-SKIP* perhaps?
7. I approve.
8. Yes, let's flush them. Or perhaps you can just write them
and hand them out to everyone else?
9. I don't care. I've already implemented it as specified but undocumenting
those things is no problem.
11. I approve.
12. This change to ~T is a pain, since it gets the character position by
simply asking the stream :READ-CURSORPOS.
15. I changed EVAL-WHEN this summer. In the compiler, if an EVAL-WHEN
appears immediately inside another EVAL-WHEN, their COMPILE and LOAD
attributes are effectively AND'ed together. I think your proposal is
essentially what it used to do, with one exception: DEFMACRO.
Evalling a DEFMACRO during compilation just causes the DEFMACRO to
be recognized for the rest of the file. A DEFMACRO inside an
EVAL-WHEN that did not include COMPILE used to be not recognized.
I think this is the reason why DEFSTRUCT has always produced
(EVAL-WHEN (COMPILE LOAD EVAL) ...)
I fixed that by making a DEFMACRO inside an EVAL-WHEN with LOAD
also be recognized for the rest of compilation. Then there was
no reason why DEFSTRUCT had to make such an EVAL-WHEN, and in fact
that was a nuisance. But I couldn't change it since the Common Lisp
manual wanted DEFSTRUCT to keep on making such EVAL-WHENs. The
only other fix was to have a way to get rid of the COMPILE in certain
situations, and that is why I made nested EVAL-WHENs AND together.
Your proposal, however, also makes it unnecessary for DEFSTRUCT
to say EVAL-WHEN COMPILE. In addition, it makes it wrong for DEFSTRUCT
to say that, because then compiling a file with a DEFSTRUCT in it
would permanently define its macros. It seems correct for DEFSTRUCT
to make no EVAL-WHEN whatever.
With this change, I will no longer need to be concerned so much with
what nested EVAL-WHENs do. As things stand, it is very difficult for
me to change anything since then there might be no way at all for me
to make certain things work.
There is a fundamental problem with DEFMACROs and EVAL-WHEN.
There seem to be four things one can do with DEFMACROs:
eval them when the file is read
eval them when the file is compiled
put them in the QFASL file
recognize them for compilation of the rest of the file
Different designs for EVAL-WHEN often differ mainly by how they let these
four options be controlled by three bits of information.
So do we really need a fourth EVAL-WHEN time? RECOGNIZE? COMPILE-FILE?
Is it clear that one never wants a DEFMACRO that is not going to be
recognized for compilation of the rest of the file?
-------
- - - - End forwarded message - - - -
∂25-Oct-83 0826 RPG Random idea
∂19-Oct-83 0912 @MIT-MC:DLW%SCRC-TENEX@MIT-MC Random idea
Received: from MIT-MC by SU-AI with TCP/SMTP; 19 Oct 83 09:11:57 PDT
Received: from SCRC-SHEPHERD by SCRC-TENEX with CHAOS; Wed 19-Oct-83 12:12:09-EDT
Date: Wednesday, 19 October 1983, 12:13-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-MC>
Subject: Random idea
To: Fahlman@CMU-CS-C, steele@CMU-CS-C, rpg@SU-AI, moon%SCRC-TENEX@MIT-MC,
bsg%SCRC-TENEX@MIT-MC, dlw%SCRC-TENEX@MIT-MC
In-reply-to: The message of 30 Sep 83 02:37-EDT from Scott E. Fahlman <Fahlman at CMU-CS-C>
I finally got around to reading the &MORE discussion (I'm struggling my
way out of my back mail, today). Just for the record, I agree with Moon.
It's OK to introduce &MORE if people really want it, but if we went back
and re-evaluated every &REST in our system, I would guess no more than
5% of them are really better off as &MOREs, 20% are just iterated over
so it really doesn't make any differerence (DOLIST and DOTIMES are equally
easy to use), and the rest are used as lists, generally for APPLY (a.k.a.
LEXPR-FUNCALL), and so very few &RESTs would get converted to &MOREs.
Anyway, that was just for the record; I don't mean to start up the
discussion again. I agree that it should wait for Common Lisp II ("Son
of Common Lisp"? "SOCL"? "Common Lisp Strikes Back?").
∂28-Oct-83 1602 RPG RMS replies to 15 hairy issues
∂28-Oct-83 1559 @MIT-ML:Moon%SCRC-TENEX@MIT-ML RMS replies to 15 hairy issues
Received: from MIT-ML by SU-AI with TCP/SMTP; 28 Oct 83 15:59:07 PDT
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 28-Oct-83 18:53:31-EDT
Date: Friday, 28 October 1983, 18:52-EDT
From: David A. Moon <Moon%SCRC-TENEX@MIT-ML>
Subject: RMS replies to 15 hairy issues
To: Guy.Steele@CMU-CS-A
Cc: Scott.Fahlman <FAHLMAN@CMU-CS-C>, rpg@SU-AI, moon%SCRC-TENEX@MIT-ML,
dlw%SCRC-TENEX@MIT-ML, bsg%SCRC-TENEX@MIT-ML
In-reply-to: The message of 25 Oct 83 10:52-EDT from Guy.Steele at CMU-CS-A
I looked over RMS's comments. I don't think he's brought up any new
issues that we need to consider, assuming my comments on the same
things didn't get overlooked (e.g. recursive-p in read).
They did bring two remarks to mind:
In his discussion of DEFSTRUCT and EVAL-WHEN, he didn't look carefully
enough at what DEFSTRUCT does. The way it is implemented leaves it
no choice but to modify the compile-time environment, because it has
to put properties on symbols such as the name of the structure. Without
a way to store those properties instead in the same data base that the
compiler uses to remember macro definitions, DEFSTRUCT has no choice
but to have an internal EVAL-WHEN (COMPILE LOAD EVAL). See my message
of Friday, 2 September 1983, 14:41-EDT.
I'm still unhappy with the vertical bars in package prefixes on qualified
names, and still unhappy with the change of #: to ::. I'd like to agitate
again for simplifying the syntax as I proposed in my message of
Friday, 7 October 1983, 22:09-EDT. Even though it would make RMS happy.
∂12-Nov-83 1117 @MIT-MC:Zvona@MIT-OZ :otherwise
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Nov 83 11:17:27 PST
Date: Friday, 11 November 1983, 14:41-EST
From: David Chapman <Zvona at MIT-OZ>
Subject: :otherwise
To: lisp-designers at SCRC-TENEX
Cc: kmp at MIT-OZ
ReSent-date: Sat 12 Nov 83 14:17:38-EST
ReSent-from: KMP%MIT-OZ@MIT-MC.ARPA
ReSent-to: common-lisp@SU-AI.ARPA
It seems bogus to me that I can't write :otherwise in a selectq.
I think that :otherwise should be required. There are reasonable
arguments against this. However, I can't see arguments against
:otherwise being *allowed*. If the idea is that it doesn't matter what
package the ``magic keyword'' (what are these things called, anyway?) is
in, then that should extend to the keyword package, too. Unless we are
moving toward the view that keywords aren't really symbols.
Speaking of which: Why are keywords bound to themselves? Why not
rather have EVAL and the compiler special-case them as self-quoting?
(Presumably the compiler already does this for T and NIL.) Surely this
would be less overhead.
∂12-Nov-83 1344 @MIT-ML:Moon%SCRC-TENEX@MIT-MC :otherwise in selectq
Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Nov 83 13:43:56 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 12-Nov-83 16:24:40-EST
Date: Sat, 12 Nov 83 16:24 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: :otherwise in selectq
To: kmp@MIT-OZ.ARPA
Cc: common-lisp@SU-AI.ARPA
References: The message of 11 Nov 83 14:41-EST from David Chapman <Zvona at MIT-OZ>
I'm not sure why Kent redistributed the enclosed message, since several
people had already replied to it pointing out the nonsensicalness of the
third paragraph, and I (and maybe others?) had already replied to it
explaining that magic syntactic words in special forms, such as OTHERWISE,
are treated like function names rather than as keywords.
Date: Friday, 11 November 1983, 14:41-EST
From: David Chapman <Zvona at MIT-OZ>
Subject: :otherwise
To: lisp-designers at SCRC-TENEX
Cc: kmp at MIT-OZ
ReSent-date: Sat 12 Nov 83 14:17:38-EST
ReSent-from: KMP%MIT-OZ@MIT-MC.ARPA
ReSent-to: common-lisp@SU-AI.ARPA
It seems bogus to me that I can't write :otherwise in a selectq.
I think that :otherwise should be required. There are reasonable
arguments against this. However, I can't see arguments against
:otherwise being *allowed*. If the idea is that it doesn't matter what
package the ``magic keyword'' (what are these things called, anyway?) is
in, then that should extend to the keyword package, too. Unless we are
moving toward the view that keywords aren't really symbols.
Speaking of which: Why are keywords bound to themselves? Why not
rather have EVAL and the compiler special-case them as self-quoting?
(Presumably the compiler already does this for T and NIL.) Surely this
would be less overhead.
∂12-Nov-83 1433 @MIT-MC:KMP%MIT-OZ@MIT-MC SELECTQ commentary
Received: from MIT-MC by SU-AI with TCP/SMTP; 12 Nov 83 14:32:29 PST
Date: Sat 12 Nov 83 17:33:00-EST
From: KMP%MIT-OZ@MIT-MC.ARPA
Subject: SELECTQ commentary
To: Moon%SCRC-TENEX@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA
Reply-To: KMP@MIT-MC
In-Reply-To: Message from ""David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>" of Sat 12 Nov 83 16:29:30-EST
Date: Sat, 12 Nov 83 16:24 EST
From: David A. Moon <Moon at SCRC-TENEX>
Re: :otherwise in selectq
References: Msg of 11 Nov 83 14:41-EST from David Chapman <Zvona at MIT-OZ>
I'm not sure why Kent redistributed the enclosed message, since
several people had already replied to it pointing out the
nonsensicalness of the third paragraph,
Sorry, I hadn't forwarded it for that part, which I agree was not realistic.
and I (and maybe others?) had already replied to it explaining
that magic syntactic words in special forms, such as OTHERWISE,
are treated like function names rather than as keywords.
As you probably know from previous discussions, I disagree with the
decision that was made on OTHERWISE vs :OTHERWISE. Since we're not in a
position to consider changing this, it would be pointless to try to
reopen that discussion here and now.
Nevertheless, it's hard to do language design in a vacuum. It is
important, for example, to follow up on decisions you've made by seeing
whether your guesses about things like users' intuitions were correct.
It might not even affect the current language, but you might some day
design another. By the way, in spite of the explicit CC to me, I didn't
put Zvona up to this bug report. Anyway, I did find the note interesting,
and thought others on CL might also. Especially since it's only in the
first few days that a Common Lisp compatible package system available
here that people are starting to evolve strong feelings about these
things.
Perhaps in a few years when it's time to contemplate major evolutionary
changes to Common Lisp, there will be a place for a little rabble rousing.
For now, that's not what I'd intended; just wanted to quietly pass on
what I saw as an interesting data point.
In the future I'll try to remember to mark such messages with an "FYI"
in the subject line or some such so it doesn't look so much like people
should want to reply to them.
-------
∂13-Nov-83 2234 RPG Functionp
∂13-Nov-83 1643 FAHLMAN@CMU-CS-C.ARPA Functionp
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 13 Nov 83 16:42:58 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 13 Nov 83 19:43:17-EST
Date: Sun, 13 Nov 1983 19:43 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA
Cc: moon%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA, rpg@SU-AI.ARPA,
bsg%SCRC-TENEX@MIT-ML.ARPA
Subject: Functionp
Is functionp of a symbol that has a function definition supposed to be
true? In other words, what is the proper value of (FUNCTIONP 'CDR) ?
I thought that this was supposed to be NIL, and implemented that, but
several users have pointed out that the manual says this function is
true of anything that can be passed to APPLY. If I'm right, that
sentence should be removed. If I'm wrong, you should make that clear
and I'll fix our implementation.
-- Scott
∂13-Nov-83 2234 RPG Functionp
∂13-Nov-83 1714 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Functionp
Received: from MIT-ML by SU-AI with TCP/SMTP; 13 Nov 83 17:14:24 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sun 13-Nov-83 20:13:25-EST
Date: Sun, 13 Nov 83 20:11 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Functionp
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: steele@CMU-CS-C.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
bsg%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 13 Nov 83 19:43-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Sun, 13 Nov 1983 19:43 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Is functionp of a symbol that has a function definition supposed to be
true? In other words, what is the proper value of (FUNCTIONP 'CDR) ?
I thought that this was supposed to be NIL
I can't see any support for this in the Excelsior manual.
It returns T in the Lisp machine, which I think is where the idea of
having FUNCTIONP came from, for whatever that precedent is worth.
∂24-Nov-83 1151 RPG URGENT! Problem with MACROLET.
∂22-Nov-83 2251 Guy.Steele@CMU-CS-A URGENT! Problem with MACROLET.
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 22 Nov 83 22:50:44 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 23 Nov 83 01:35:57 EST
Date: 23 Nov 83 0146 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: rpg@SU-AI, fahlman@CMU-CS-C, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, rms@MIT-MC, bsg%scrc-tenex@MIT-MC
Subject: URGENT! Problem with MACROLET.
I have encountered a problem with macrolet and macroexpand. The correct
fix involves some rather large changes, and there is very little time
to deal with them. Sorry for the short notice, but UNLESS WE CAN AGREE
ON THE FIX PROPOSED HERE OR SOMETHING MUCH LIKE IT VERY SOON (LIKE
SATURDAY), I WILL BE FORCED TO REMOVE MACROLET FROM THE COMMON LISP
MANUAL. (Indeed, we might well just decide that removal of macrolet is
the best solution anyway.)
Consider this example:
(defmacro foo (x)
(let ((z (macroexpand x)))
(if (and (consp z) (eq (car z) 'remove-if))
(horrible-remove-if-hack z)
(normal-foo-expansion z))))
(defun frobboz (q)
(macrolet ((snert (w) `(remove-if #'numberp ,w)))
(foo (snert q))))
When the call (foo (snert q)) is to be executed, it must first be expanded.
The expansion function for foo is called; it gets the entire call as an
argument, and by defmacro magic x is bound to "(snert q)". This is then
given to macroexpand. Question: how can macroexpand know about the
definition of the local macro snert? Answer: only if it is handed the
relevant lexical environment; this can be done, for indeed the Excelsior
edition specifies that macroexpand may take an env as a &rest argument.
Big question: what environment to give to macroexpand? Non-answer:
the macro expansion function does not have this environment available to it.
The necessary fix seems to be as follows:
(1) Macro expansion functions must receive a lexical environment as a &rest
argument in much the same way that macroexpand and evalhook do. This
environment is important only for the sake of local macro definitions;
it would be anomalous to use the environment for any other purpose.
(Receiving this extra set of arguments would not be obtrusive because
the defmacro and macrolet syntax would tend to hide them; see (3) below.)
(2) When macroexpand calls the *macroexpand-hook* function, it must pass
not only the expansion function and the hook, but also the env.
(Note that the default value of *macroexpand-hook* is still funcall.)
(3) There must be a way in defmacro and macrolet to get at this environment.
I propose that "&env varname" be used in the parameter list.
(4) When the compiler performs macro expansion, it must pass the expansion
function something that looks like a lexical environment, again for the
sake of any local (macrolet) macro definitions that may be visible from
the point of the macro call; this environment must be acceptable to
macroexpand.
(5) An only slightly related topic: macro expansion functions created by
defmacro probably ought also be closed in the global environment, just
as for macrolet.
With these fixes, the example above may be rewritten as follows:
(defmacro foo (x &env e)
(let ((z (apply #'macroexpand x e)))
(if (and (consp z) (eq (car z) 'remove-if))
(horrible-remove-if-hack z)
(normal-foo-expansion z))))
I believe this is all proper and consistent. I would like each of
you to respond ASAP, and specify which of these options you judge best:
(1) I like this fix.
(2) I like this fix, with the following emendations...
(3) Flush macrolet.
--Guy
∂24-Nov-83 1151 RPG URGENT! Problem with MACROLET.
∂22-Nov-83 2326 FAHLMAN@CMU-CS-C.ARPA URGENT! Problem with MACROLET.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Nov 83 23:26:44 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 23 Nov 83 02:28:18-EST
Date: Wed, 23 Nov 1983 02:28 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Guy.Steele@CMU-CS-A.ARPA
Cc: bsg%scrc-tenex@MIT-MC.ARPA, dlw%scrc-tenex@MIT-MC.ARPA,
moon%scrc-tenex@MIT-MC.ARPA, rms@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: URGENT! Problem with MACROLET.
In-reply-to: Msg of 23 Nov 83 0146 EST () from Guy.Steele at CMU-CS-A
I think that Guy's proposal hangs together and I could live with it, I
think. It is awkward to implement -- it requires the compiler to dummy
up a fake interpreter-style lexical environment in some cases -- but not
really hard.
However, I would very much prefer to flush Macrolet. It is a
convenience in some cases, but Guy's note should be sufficient to prove
that this is a rather confusing construct when coupled with lexical
scoping. Do we really want to lay this trip on the users? Macros are
tricky enough for people to understand without adding this extra layer
of hair.
-- Scott
∂24-Nov-83 1151 RPG SETF madness, again (serious)
∂22-Nov-83 2338 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA SETF madness, again (serious)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 22 Nov 83 23:38:34 PST
Received: from TARTAN by CMU-CS-C with TLnet; 23 Nov 83 02:39:36-EST
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Wed 23 Nov 83 02:36:56-EST
Date: Wed 23 Nov 83 02:36:52-EST
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: SETF madness, again (serious)
To: moon%scrc-tenex@MIT-MC.ARPA, gsb@MIT-MC.ARPA, alan@MIT-MC.ARPA,
fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, dlw%scrc-tenex@MIT-MC.ARPA
In accordance with GSB's note, I changed the example in Excelsior,
and specify now that the temporary variables and value forms
resulting from a setf method are processed as if by let*, not let.
Is the new example correct?
Old example:
(define-setf-method ldb (bytespec int)
(multiple-value-bind (temps vals stores
store-form access-form)
(get-setf-method int) ;Get SETF method for int.
(let ((btemp (gensym)) ;Temp var for byte specifier.
(store (gensym)) ;Temp var for byte to store.
(itemp (first stores))) ;Temp var for int to store.
;; Return the SETF method for LDB as five values.
(values (cons btemp temps) ;Temporary variables.
(cons bytespec vals) ;Value forms.
(list store) ;Store variables.
`(let ((,itemp (dpb ,store ,btemp ,access-form)))
,store-form
,store) ;Storing form.
`(ldb ,btemp ,access-form) ;Accessing form.
))))
New example:
(define-setf-method ldb (bytespec int)
(multiple-value-bind (temps vals stores
store-form access-form)
(get-setf-method int) ;Get SETF method for int.
(let ((btemp (gensym)) ;Temp var for byte specifier.
(store (gensym)) ;Temp var for byte to store.
(stemp (first stores))) ;Temp var for int to store.
;; Return the SETF method for LDB as five values.
(values `(,btemp ,@temps ,stemp) ;Temporary variables.
`(,bytespec ,@vals (dpb ,store ,btemp ,access-form))
;Value forms.
(list store) ;Store variables.
`(progn ,store-form ,store) ;Storing form.
`(ldb ,btemp ,access-form) ;Accessing form.
))))
--Guy
-------
∂24-Nov-83 1152 RPG SETF madness, again (serious)
∂22-Nov-83 2356 ALAN@MIT-MC SETF madness, again (serious)
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Nov 83 23:55:53 PST
Date: 23 November 1983 03:00 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: SETF madness, again (serious)
To: STEELE%TARTAN @ CMU-CS-C
cc: GSB @ MIT-MC, rpg @ SU-AI, fahlman @ CMU-CS-C, dlw @ SCRC-TENEX,
moon @ SCRC-TENEX
In-reply-to: Msg of Wed 23 Nov 83 02:36:52-EST from STEELE%TARTAN at CMU-CS-C.ARPA
That looks right to me. It agrees well with my personal implementation of
this madness.
∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 0621 Mailer@MIT-XX URGENT! Problem with MACROLET.
Received: from MIT-XX by SU-AI with TCP/SMTP; 23 Nov 83 06:21:24 PST
Received: from SCRC-CHICOPEE by SCRC-QUABBIN with CHAOS; Wed 23-Nov-83 09:20:11-EST
Date: Wed, 23 Nov 83 09:23 EST
From: "Daniel L. Weinreb" <DLW%SCRC-TENEX@MIT-MC.ARPA>
Subject: URGENT! Problem with MACROLET.
To: Guy.Steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA, fahlman@CMU-CS-C.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, bsg%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 23 Nov 83 01:46-EST from Guy.Steele at CMU-CS-A
I guess I am beginning to get totally haired out by all this. I would
not shed any tears if macrolet were removed. On the other hand, I'm
happy with your redefinition if people want to keep macrolet. I do not
claim to have done any careful analysis of the issues, though.
∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 0645 @MIT-MC:BSG%SCRC-TENEX@MIT-MC URGENT! Problem with MACROLET.
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Nov 83 06:45:33 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Wed 23-Nov-83 09:46:09-EST
Date: Wed, 23 Nov 83 09:45 EST
From: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Subject: URGENT! Problem with MACROLET.
To: Guy.Steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA, fahlman@CMU-CS-C.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
rms@MIT-MC.ARPA
In-reply-to: The message of 23 Nov 83 01:46-EST from Guy.Steele at CMU-CS-A
Date: 23 Nov 83 0146 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
I have encountered a problem with macrolet and macroexpand.
I believe this is all proper and consistent. I would like each of
you to respond ASAP, and specify which of these options you judge best:
(1) I like this fix.
I like this fix. It is in no way any more subtle than the environment
issue for the evaluator and is completely consistent with the language.
Macrolet and macroexpand are necessarily hairy, and are broken without this.
I think macrolet fills a very real language and modularity need that I
have felt many times. I really think this is a small and necessary bug
fix. SEF's remarks about it not being so hard are appropriate. His
remarks about "too hairy already" are less appropriate.
∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 0744 FAHLMAN@CMU-CS-C.ARPA URGENT! Problem with MACROLET.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 23 Nov 83 07:44:25 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 23 Nov 83 10:46:04-EST
Date: Wed, 23 Nov 1983 10:46 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rms@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: URGENT! Problem with MACROLET.
In-reply-to: Msg of 23 Nov 1983 09:45-EST from "Bernard S. Greenberg" <BSG%SCRC-TENEX at MIT-MC.ARPA>
Gee, I thought that everything I said was appropriate. It is quite
possibly wrong -- I've been wrong a lot lately -- but appropriate
to this discussion nevertheless. We're balancing the usefulness of
MACROLET against its complexity as seen by the user and the implementor,
and we're getting different answers.
I think macrolet fills a very real language and modularity need that I
have felt many times.
It would help me to swallow MACROLET, toupee and all, if I shared this
experience. I just can't think of any use that I would make of macrolet
that I could not do just as well without it. Could you supply us with
an example or two?
-- Scott
∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 1005 @MIT-MC:BSG%SCRC-TENEX@MIT-MC URGENT! Problem with MACROLET.
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Nov 83 10:05:34 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Wed 23-Nov-83 11:25:19-EST
Date: Wed, 23 Nov 83 11:24 EST
From: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Subject: URGENT! Problem with MACROLET.
To: Fahlman@CMU-CS-C.ARPA
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rms@MIT-MC.ARPA, rpg@SU-AI.ARPA
In-reply-to: The message of 23 Nov 83 10:46-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Wed, 23 Nov 1983 10:46 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
Gee, I thought that everything I said was appropriate. It is quite
possibly wrong -- I've been wrong a lot lately -- but appropriate
to this discussion nevertheless.
I'm sorry. I apologize fully. I really meant (right, wrong).
We're balancing the usefulness of
MACROLET against its complexity as seen by the user and the implementor,
and we're getting different answers.
The INCREMENTAL complexity of MACROLET, or GLS' proposed change,
is not great for either.
I think macrolet fills a very real language and modularity need that I
have felt many times.
It would help me to swallow MACROLET, toupee and all, if I shared this
experience. I just can't think of any use that I would make of macrolet
that I could not do just as well without it. Could you supply us with
an example or two?
-- Scott
I needed it this VERY MORNING seeking out a file-system bug.
Here is a previous time I wanted it:
Real extant code coming up....
;;FROM SYS: LMFS; DUMPER LISP
(defmacro bdva-error body
`(progn
(format t . ,body)
(return-from backup-dump-validate-args nil)))
(defun backup-dump-validate-args () ;everything special, thx to choose-v-v
(prog backup-dump-validate-args ()
(setq *backup-dump-tape-drive*
(cond ((numberp *backup-dump-tape-drive*)
(format nil "~D" *backup-dump-tape-drive*))
(t (string-trim '(#\SP) *backup-dump-tape-drive*))))
(if (eq *backup-dump-type* ':archive)
(bdva-error "~&Archival dumps not supported yet."))
(if (string-equal *backup-tape-host* "")
(bdva-error "~&A tape host must be specified."))
(if (not (or (string-equal *backup-tape-host* "Local")
(si:parse-host *backup-tape-host* t)))
(bdva-error "~&Unknown tape host: ~A" *backup-tape-host*))
........
(return t)))
This is very silly, this bdva-error macro. The reason it has bdva- in
its name is because backup-dump-validate-args-error is too hard to type,
and is going to be called 50 times in backup-dump-validate-args.
It should be
(defun backup-dump-validate-args () ;everything special, thx to choose-v-v
(macrolet ((err-out body
`(progn
(format t . ,body)
(return-from backup-dump-validate-args nil))))
(prog backup-dump-validate-args ()
(setq *backup-dump-tape-drive*
(cond ((numberp *backup-dump-tape-drive*)
(format nil "~D" *backup-dump-tape-drive*))
(t (string-trim '(#\SP) *backup-dump-tape-drive*))))
(if (eq *backup-dump-type* ':archive)
(err-out "~&Archival dumps not supported yet."))
(if (string-equal *backup-tape-host* "")
(err-out "~&A tape host must be specified."))
(if (not (or (string-equal *backup-tape-host* "Local")
(si:parse-host *backup-tape-host* t)))
(err-out "~&Unknown tape host: ~A" *backup-tape-host*))
........
(return t)))
or whatever. This is exactly the conceptual scoping of this name
which is desired. The name or availability of this macro should
NOT EXIST outside of this function.
∂24-Nov-83 1152 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 1012 FAHLMAN@CMU-CS-C.ARPA URGENT! Problem with MACROLET.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 23 Nov 83 10:11:56 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 23 Nov 83 13:13:33-EST
Date: Wed, 23 Nov 1983 13:13 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, Guy.Steele@CMU-CS-A.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rms@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: URGENT! Problem with MACROLET.
In-reply-to: Msg of 23 Nov 1983 11:24-EST from "Bernard S. Greenberg" <BSG%SCRC-TENEX at MIT-MC.ARPA>
OK, I guess I see Bernie's point about the usefulness of macrolet. I'm
a litle scared of Guy's scheme on the grounds that, until I've thought
through the details of implementing it, I might be missing some
additional deep bugs. Unfortunately, I'm just about to leave town for
four days, so I can't implement this thing right away and see. But if
one or two of you can give this some thought and come away convinced
that you know exactly what has to be done in both the interpreter and
compiler and that there are no residual nasties, I'm happy to go along
with Guy's proposal.
-- Scott
∂24-Nov-83 1152 RPG SETF madness, again (serious)
∂23-Nov-83 1357 @MIT-ML:Moon%SCRC-TENEX@MIT-MC SETF madness, again (serious)
Received: from MIT-ML by SU-AI with TCP/SMTP; 23 Nov 83 13:56:45 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 23-Nov-83 16:56:28-EST
Date: Wed, 23 Nov 83 16:56 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: SETF madness, again (serious)
To: STEELE%TARTAN@CMU-CS-C.ARPA
Cc: gsb@MC.ARPA, alan@MC.ARPA, fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA,
dlw%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 23 Nov 83 02:36-EST from STEELE%TARTAN at CMU-CS-C
Date: Wed 23 Nov 83 02:36:52-EST
From: STEELE%TARTAN@CMU-CS-C.ARPA
In accordance with GSB's note, I changed the example in Excelsior,
and specify now that the temporary variables and value forms
resulting from a setf method are processed as if by let*, not let.
Using LET* instead of LET is right.
Is the new example correct?
The new example is incorrect. It assumes that the "store" variables are
bound outside of the "temporary" variables. But ROTATEF has to bind the
"store" variables inside of the "temporary" variables. The "store"
variables must be treated independently of the "temporary" variables.
Think of (ROTATEF (LDB A B) (LDB C D)).
I can send you a copy of this message if you don't still have it. It
discussed these issues at greater length:
Date: Friday, 14 October 1983, 15:55-EDT
From: David A. Moon <Moon at SCRC-TENEX>
Subject: Hairy SETF issues
For reference, here are the examples from Guy's message:
Old example:
(define-setf-method ldb (bytespec int)
(multiple-value-bind (temps vals stores
store-form access-form)
(get-setf-method int) ;Get SETF method for int.
(let ((btemp (gensym)) ;Temp var for byte specifier.
(store (gensym)) ;Temp var for byte to store.
(itemp (first stores))) ;Temp var for int to store.
;; Return the SETF method for LDB as five values.
(values (cons btemp temps) ;Temporary variables.
(cons bytespec vals) ;Value forms.
(list store) ;Store variables.
`(let ((,itemp (dpb ,store ,btemp ,access-form)))
,store-form
,store) ;Storing form.
`(ldb ,btemp ,access-form) ;Accessing form.
))))
New example:
(define-setf-method ldb (bytespec int)
(multiple-value-bind (temps vals stores
store-form access-form)
(get-setf-method int) ;Get SETF method for int.
(let ((btemp (gensym)) ;Temp var for byte specifier.
(store (gensym)) ;Temp var for byte to store.
(stemp (first stores))) ;Temp var for int to store.
;; Return the SETF method for LDB as five values.
(values `(,btemp ,@temps ,stemp) ;Temporary variables.
`(,bytespec ,@vals (dpb ,store ,btemp ,access-form))
;Value forms.
(list store) ;Store variables.
`(progn ,store-form ,store) ;Storing form.
`(ldb ,btemp ,access-form) ;Accessing form.
))))
--Guy
-------
∂24-Nov-83 1152 RPG SETF madness, again (serious)
∂23-Nov-83 1358 @MIT-ML:Moon%SCRC-TENEX@MIT-MC SETF madness, again (serious)
Received: from MIT-ML by SU-AI with TCP/SMTP; 23 Nov 83 13:58:17 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 23-Nov-83 16:59:21-EST
Date: Wed, 23 Nov 83 16:59 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: SETF madness, again (serious)
To: STEELE%TARTAN@CMU-CS-C.ARPA
Cc: gsb@MC.ARPA, alan@MC.ARPA, fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA,
dlw%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 23 Nov 83 02:36-EST from STEELE%TARTAN at CMU-CS-C
By the way, the new example doesn't even work for INCF. So if my
ROTATEF example hairs you out, just think about INCF of LDB.
∂24-Nov-83 1153 RPG URGENT! Problem with MACROLET.
∂23-Nov-83 1448 @MIT-MC:Moon%SCRC-TENEX@MIT-MC URGENT! Problem with MACROLET.
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Nov 83 14:48:06 PST
Received: from SCRC-EUPHRATES by SCRC-YUKON with CHAOS; Wed 23-Nov-83 17:43:41-EST
Date: Wed, 23 Nov 83 17:39 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: URGENT! Problem with MACROLET.
To: Guy.Steele@CMU-CS-A.ARPA, "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>,
"Daniel L. Weinreb" <DLW%SCRC-TENEX@MIT-MC.ARPA>,
"Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: rpg@SU-AI.ARPA, rms@MC.ARPA
In-reply-to: The message of 23 Nov 83 01:46-EST from Guy.Steele at CMU-CS-A,
The message of 23 Nov 83 02:28-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 23 Nov 83 09:23-EST from Daniel L. Weinreb <DLW at SCRC-TENEX>,
The message of 23 Nov 83 09:45-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>,
The message of 23 Nov 83 10:46-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 23 Nov 83 11:24-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>,
The message of 23 Nov 83 13:13-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
I agree with Guy's proposed fix. It is self-evidently right.
I still don't understand why lexical environments are &rest arguments,
rather than a single ordinary argument. Perhaps I just don't understand.
∂24-Nov-83 1153 RPG Re: SETF madness, again (serious)
∂23-Nov-83 1456 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA Re: SETF madness, again (serious)
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 23 Nov 83 14:56:47 PST
Received: from TARTAN by CMU-CS-C with TLnet; 23 Nov 83 17:57:43-EST
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Wed 23 Nov 83 17:55:13-EST
Date: Wed 23 Nov 83 17:55:11-EST
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: Re: SETF madness, again (serious)
To: Moon%SCRC-TENEX@MIT-MC.ARPA
cc: gsb@MIT-MC.ARPA, alan@MIT-MC.ARPA, fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA,
dlw%SCRC-TENEX@MIT-MC.ARPA, STEELE%TARTAN@CMU-CS-C.ARPA, guy.steele@CMU-CS-A.ARPA
In-Reply-To: Message from ""David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>" of Wed 23 Nov 83 17:14:22-EST
Well, if the LDB example cannot oeprate by depending on the temps
using LET* order instead of LET order, but must introduce its own nested
LET, then I cannot think of an example where the LET* ordering
is more useful than LET ordering. Can someone provide an example
in the form of a DEFINE-SETF-METHOD definition?
--Guy
-------
∂24-Nov-83 1509 RPG Macrolet
To: steele@CMU-CS-C, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, rms@MIT-MC, bsg%scrc-tenex@MIT-MC,
fahlman@CMU-CS-C, "#COMMON.MSG[COM,LSP]"@SU-AI
I think that MACROLET, for all its good intentions, is an idea
not well thought out. Consider the following example:
(defun frobboz (q)
(macrolet ((snert (w) `(,(trens (car w)) . `(remove-if #'numberp ,(cdr w))))
(trens (w)` (,(snert w) `(add-if #'numberp ,(cdr w)))))
(foo (snert q))))
Although it doesn't make much sense as a program, the point is: Is there
is a MACROLABELS as well as a MACROLET, as there is a LABELS as well as
a LET?
Another problem I didn't really think about oo much before is why is
the environment a &REST argument and not an &OPTIONAL? Is that supposed to
mean that an environment can be a mess instead of some object?
And is it the case that MACROLET helps confuse compile-time binding or
execution with run-time binding or execution? In other words, MACROLET
requires a certain type of optimization to take place, namely, partial
evaluation of a different sort from normal macro expansion. Why can't a
compiler just emit code to build the MACROLET environment and than
emit (EVAL '(FOO (SNERT Q)) <env>) above?
I'm just not sure we've thought it out well enough.
-rpg-
∂26-Nov-83 1322 RPG Varia
To: "@CLCORE.[1,RPG]"@SU-AI
1. Is the language frozen in areas where it is broken? Inconsistent?
If we realize that a construct is inadequate must we wait for round 2
to fix it? How do we explain to people that CL code that we produce is
different from the manual because we know the manual is wrong? I think
we ought to establish an errata system now, and use it to fix MACROLET,
if it needs to be fixed.
2. &rest environments are a gross mistake. I say to &optional it.
-rpg-
∂26-Nov-83 1534 @MIT-ML:MOON@SCRC-TENEX Macrolet
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 15:34:08 PST
Date: Saturday, 26 November 1983 18:33-EST
From: MOON at SCRC-TENEX
To: Dick Gabriel <RPG at SU-AI>
Cc: "#COMMON.MSG[COM, LSP]" at SU-AI, bsg%scrc-tenex at MIT-MC,
dlw%scrc-tenex at MIT-MC, fahlman at CMU-CS-C,
moon%scrc-tenex at MIT-MC, rms at MIT-MC, steele at CMU-CS-C
Subject: Macrolet
In-reply-to: The message of 24 Nov 83 1509 PST from Dick Gabriel <RPG@SU-AI>
Date: 24 Nov 83 1509 PST
From: Dick Gabriel <RPG@SU-AI>
Subject: Macrolet
To: steele@CMU-CS-C, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, rms@MIT-MC, bsg%scrc-tenex@MIT-MC,
fahlman@CMU-CS-C, "#COMMON.MSG[COM,LSP]"@SU-AI
I think that MACROLET, for all its good intentions, is an idea
not well thought out. Consider the following example:
(defun frobboz (q)
(macrolet ((snert (w) `(,(trens (car w)) . `(remove-if #'numberp ,(cdr w))))
(trens (w)` (,(snert w) `(add-if #'numberp ,(cdr w)))))
(foo (snert q))))
Although it doesn't make much sense as a program, the point is: Is there
is a MACROLABELS as well as a MACROLET, as there is a LABELS as well as
a LET?
As with too many subtle points, the manual (at least the Laser edition
I have where I currently am) is completely silent about this. But my
impression was that MACROLET only affects the environment for macro
expansion, not the environment for running code at compile time, and
hence the two versions of MACROLET (a la FLET/LABELS) would be identical.
To say the same thing in different language, MACROLET closes the bodies
of the macro-expansion functions it defines over the global environment,
not the current environment.
If your example made sense as a program, it would be screwed by this.
Can we construct a real example that would be screwed?
Another problem I didn't really think about too much before is why is
the environment a &REST argument and not an &OPTIONAL? Is that supposed to
mean that an environment can be a mess instead of some object?
My opinion is that it should be an object, and should be required, not
optional, expressed in a previous letter today. Well, by required I
mean that functions to which an argument could be passed should be required
to receive it. It makes sense to make it &optional in EVAL and MACROEXPAND,
letting it default to the global environment.
I had a braino that went "Say, where is the environment-taking version
of APPLY". I hope everyone on this list understands why this is a braino.
For elucidation see the definition of EVAL on p.71 of the Lisp 1.5
Reference Manual; it uses APPLY with three arguments because in Lisp 1.5
there is no distinction between lexically-bound and dynamically-bound
variables; the same deep binding mechanism is used for both, causing
all sorts of anomalies. I guess this is the thing that always bothered
me about Interlisp.
And is it the case that MACROLET helps confuse compile-time binding or
execution with run-time binding or execution? In other words, MACROLET
requires a certain type of optimization to take place, namely, partial
evaluation of a different sort from normal macro expansion. Why can't a
compiler just emit code to build the MACROLET environment and than
emit (EVAL '(FOO (SNERT Q)) <env>) above?
It is quite possible that I don't understand this, but I think the answer
is that the compiler can do this, and the reason why it can is because
bodies of local macro expanders are closed over the global environment.
Maybe Guy can illuminate us.
∂29-Nov-83 0914 RPG Macrolet
∂26-Nov-83 1114 @MIT-ML:DLW@SCRC-TENEX Macrolet
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 11:13:57 PST
Received: from SCRC-CHICOPEE by SCRC-TENEX with CHAOS; Sat 26-Nov-83 14:12:29-EST
Date: Saturday, 26 November 1983, 14:10-EST
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
Subject: Macrolet
To: RPG at SU-AI, steele at CMU-CS-C, moon at SCRC-TENEX,
bsg at SCRC-TENEX, fahlman at CMU-CS-C
In-reply-to: The message of 24 Nov 83 18:09-EST from Dick Gabriel <RPG at SU-AI>
Since the Common Lisp definition is officially frozen, I don't think it
is reasonable to remove MACROLET unless there is an overriding reason to
do so. Without getting into an actual debate over the points that you
raise in your mail, I don't think any of them is of sufficient magnitude
to justify removing MACROLET at this late date.
I wasn't suggesting removing MACROLET so much as cleaning it up.
∂29-Nov-83 0914 RPG &rest environments
∂26-Nov-83 1149 Guy.Steele@CMU-CS-A &rest environments
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 26 Nov 83 11:48:57 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 26 Nov 83 14:33:44 EST
Date: 26 Nov 83 1445 EST (Saturday)
From: Guy.Steele@CMU-CS-A
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC>
Subject: &rest environments
CC: fahlman@CMU-CS-C, dlw%scrc-tenex@MIT-MC, bsg%scrc-tenex@MIT-MC,
rpg@SU-AI, rms@MIT-MC
In-Reply-To: "\"David A. Moon\"'s message of 23 Nov 83 17:39-EST"
I suppose that the &rest-ness of environments is an artifiact of my
initial implementations. Experience indicated that the amount of consing,
and also the speed of searching, could be improved dramatically by
maintaining several distinct a-lists, one for each class of bindings.
However, I now believe that letting this become visible to the user
was a gross mistake, primarily because it results in such messes as
(apply #'macroexpand x env)
I am reluctant to change this, however, as I am reluctant to make any change.
What do you all think?
--Guy
∂29-Nov-83 0915 RPG Re: &rest environments
∂26-Nov-83 1454 @MIT-ML:BSG%SCRC-TENEX@MIT-ML Re: &rest environments
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 14:54:11 PST
Date: 26 Nov 1983 1751-EST
From: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML>
Subject: Re: &rest environments
To: Guy.Steele@CMU-CS-A
cc: Moon%SCRC-TENEX@MIT-MC, fahlman@CMU-CS-C, dlw%scrc-tenex@MIT-MC,
bsg%scrc-tenex@MIT-MC, rpg@SU-AI, rms@MIT-MC
In-Reply-To: The message of 26 Nov 83 1445 EST (Saturday) from Guy.Steele@CMU-CS-A
Return-path: <Guy.Steele@CMU-CS-A>
Received: from MIT-MC by SCRC-TENEX with CHAOS; Sat 26-Nov-83 14:50:12-EST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 26 Nov 83 14:33:23 EST
Date: 26 Nov 83 1445 EST (Saturday)
From: Guy.Steele@CMU-CS-A
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC>
Subject: &rest environments
CC: fahlman@CMU-CS-C, dlw%scrc-tenex@MIT-MC, bsg%scrc-tenex@MIT-MC,
rpg@SU-AI, rms@MIT-MC
In-Reply-To: "\"David A. Moon\"'s message of 23 Nov 83 17:39-EST"
I suppose that the &rest-ness of environments is an artifiact of my
initial implementations. Experience indicated that the amount of consing,
and also the speed of searching, could be improved dramatically by
maintaining several distinct a-lists, one for each class of bindings.
However, I now believe that letting this become visible to the user
was a gross mistake, primarily because it results in such messes as
(apply #'macroexpand x env)
I am reluctant to change this, however, as I am reluctant to make any change.
What do you all think?
--Guy
--------
It stinks. No one, esp. you, likes it. I hate it. Change it. Thanks.
-------
∂29-Nov-83 0915 RPG &rest environments
∂26-Nov-83 1514 @MIT-ML:MOON@SCRC-TENEX &rest environments
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 15:14:34 PST
Date: Saturday, 26 November 1983 18:15-EST
From: MOON at SCRC-TENEX
To: Guy.Steele at CMU-CS-A
Cc: bsg at SCRC-TENEX, dlw at SCRC-TENEX, moon at SCRC-TENEX,
fahlman at CMU-CS-C, rms at MIT-MC, rpg at SU-AI, gsb at ml
Subject: &rest environments
In-reply-to: The message of 26 Nov 83 1445 EST () from Guy.Steele@CMU-CS-A
Date: 26 Nov 83 1445 EST (Saturday)
From: Guy.Steele@CMU-CS-A
I suppose that the &rest-ness of environments is an artifiact of my
initial implementations. Experience indicated that the amount of consing,
and also the speed of searching, could be improved dramatically by
maintaining several distinct a-lists, one for each class of bindings.
However, I now believe that letting this become visible to the user
was a gross mistake, primarily because it results in such messes as
(apply #'macroexpand x env)
I agree with this. Have distinct alists for each class of bindings, but
be a little more sophisticated about how you pass them through user
functions. I don't think using a field-extractor macro (a la defstruct)
to get the appropriate alist out of the environment object before
searching it has to have significant cost. And the environment objects
can be made on the stack in implementations that have stack objects.
I am reluctant to change this, however, as I am reluctant to make any change.
I think this is worth changing. I don't think that there is any deep
committment to the &rest way of doing it, since only one implementation
has a lexical interpreter yet, and they haven't had it for very long.
(I'm leaving aside NIL, which has always had a lexical interpreter, which
I assume is not a Common Lisp one yet. The NIL interpreter uses
something that could be called "shallow lexical binding", however if
I understand it I think it still makes sense to pass around environment
objects there; they just have a little different contents.)
Also it doesn't look like the &rest way of doing things was so well
thought out that by changing it we risk breaking something subtle.
I don't think the environment should be &optional. It should be
a required argument where it appears. It should be &ENV in defmacro,
not required to appear since usually a macro does not call macroexpand.
I believe there was originally the idea that making the environment &rest
would allow it to be null, as a concession to CL implementations that
don't have lexical scoping yet. Speaking in my capacity as proprietor
of the implementation that is going to have the most trouble putting
in lexical scoping, I say this line of reasoning is ridiculous.
BTW I feel that abbreviations are near the root of much that is
wrong with computer science today. Can we call the defmacro
option &ENVIRONMENT? I don't think it's used enough to justify
an abbreviation.
∂29-Nov-83 0915 RPG &rest environments
∂26-Nov-83 1528 GSB@MIT-ML &rest environments
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 15:28:10 PST
Date: 26 November 1983 18:30 EST
From: Glenn S. Burke <GSB @ MIT-ML>
Subject: &rest environments
To: MOON @ SCRC-TENEX
cc: GSB @ MIT-ML, rpg @ SU-AI, Guy.Steele @ CMU-CS-A,
fahlman @ CMU-CS-C, rms @ MIT-MC, bsg @ SCRC-TENEX,
dlw @ SCRC-TENEX
actually I think the nil interpreter is fairly close to CL now,
mainly modulo a few dead bears i haven't had the initiative to
tackle yet like defmacro and macro expansion details. The environment
structure is a single object which happens to be implemented
as a lexical closure over an internal evaluator function, so
evaluating something in an environment works by funcalling the
environment on the form. (The object is a distinct type however.)
The stepper does not know that only one argument is passed however;
it would be nice to get rid of all those &rests and applys.
∂29-Nov-83 0917 RPG Macrolet
∂26-Nov-83 1534 @MIT-ML:MOON@SCRC-TENEX Macrolet
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 15:34:08 PST
Date: Saturday, 26 November 1983 18:33-EST
From: MOON at SCRC-TENEX
To: Dick Gabriel <RPG at SU-AI>
Cc: "#COMMON.MSG[COM, LSP]" at SU-AI, bsg%scrc-tenex at MIT-MC,
dlw%scrc-tenex at MIT-MC, fahlman at CMU-CS-C,
moon%scrc-tenex at MIT-MC, rms at MIT-MC, steele at CMU-CS-C
Subject: Macrolet
In-reply-to: The message of 24 Nov 83 1509 PST from Dick Gabriel <RPG@SU-AI>
Date: 24 Nov 83 1509 PST
From: Dick Gabriel <RPG@SU-AI>
Subject: Macrolet
To: steele@CMU-CS-C, moon%scrc-tenex@MIT-MC,
dlw%scrc-tenex@MIT-MC, rms@MIT-MC, bsg%scrc-tenex@MIT-MC,
fahlman@CMU-CS-C, "#COMMON.MSG[COM,LSP]"@SU-AI
I think that MACROLET, for all its good intentions, is an idea
not well thought out. Consider the following example:
(defun frobboz (q)
(macrolet ((snert (w) `(,(trens (car w)) . `(remove-if #'numberp ,(cdr w))))
(trens (w)` (,(snert w) `(add-if #'numberp ,(cdr w)))))
(foo (snert q))))
Although it doesn't make much sense as a program, the point is: Is there
is a MACROLABELS as well as a MACROLET, as there is a LABELS as well as
a LET?
As with too many subtle points, the manual (at least the Laser edition
I have where I currently am) is completely silent about this. But my
impression was that MACROLET only affects the environment for macro
expansion, not the environment for running code at compile time, and
hence the two versions of MACROLET (a la FLET/LABELS) would be identical.
To say the same thing in different language, MACROLET closes the bodies
of the macro-expansion functions it defines over the global environment,
not the current environment.
If your example made sense as a program, it would be screwed by this.
Can we construct a real example that would be screwed?
Another problem I didn't really think about too much before is why is
the environment a &REST argument and not an &OPTIONAL? Is that supposed to
mean that an environment can be a mess instead of some object?
My opinion is that it should be an object, and should be required, not
optional, expressed in a previous letter today. Well, by required I
mean that functions to which an argument could be passed should be required
to receive it. It makes sense to make it &optional in EVAL and MACROEXPAND,
letting it default to the global environment.
I had a braino that went "Say, where is the environment-taking version
of APPLY". I hope everyone on this list understands why this is a braino.
For elucidation see the definition of EVAL on p.71 of the Lisp 1.5
Reference Manual; it uses APPLY with three arguments because in Lisp 1.5
there is no distinction between lexically-bound and dynamically-bound
variables; the same deep binding mechanism is used for both, causing
all sorts of anomalies. I guess this is the thing that always bothered
me about Interlisp.
And is it the case that MACROLET helps confuse compile-time binding or
execution with run-time binding or execution? In other words, MACROLET
requires a certain type of optimization to take place, namely, partial
evaluation of a different sort from normal macro expansion. Why can't a
compiler just emit code to build the MACROLET environment and than
emit (EVAL '(FOO (SNERT Q)) <env>) above?
It is quite possible that I don't understand this, but I think the answer
is that the compiler can do this, and the reason why it can is because
bodies of local macro expanders are closed over the global environment.
Maybe Guy can illuminate us.
∂29-Nov-83 0917 RPG Re: SETF madness, again (serious)
∂26-Nov-83 2239 @MIT-ML:MOON@SCRC-TENEX Re: SETF madness, again (serious)
Received: from MIT-ML by SU-AI with TCP/SMTP; 26 Nov 83 22:39:21 PST
Date: Sunday, 27 November 1983 01:38-EST
From: MOON at SCRC-TENEX
To: STEELE%TARTAN at CMU-CS-C
Cc: alan at MIT-MC, dlw at SCRC-TENEX, fahlman at CMU-CS-C,
gsb at MIT-MC, guy.steele at CMU-CS-A, Moon at SCRC-TENEX,
BSG at SCRC-TENEX, rpg at SU-AI
Subject: Re: SETF madness, again (serious)
In-reply-to: The message of Wed 23 Nov 83 17:55:11-EST from STEELE%TARTAN@CMU-CS-C.ARPA
Date: Wed 23 Nov 83 17:55:11-EST
From: STEELE%TARTAN@CMU-CS-C.ARPA
Well, if the LDB example cannot oeprate by depending on the temps
using LET* order instead of LET order, but must introduce its own nested
LET, then I cannot think of an example where the LET* ordering
is more useful than LET ordering. Can someone provide an example
in the form of a DEFINE-SETF-METHOD definition?
In any case it should use LET* because it is slightly more general.
But here is a somewhat contrived example that depends on using
LET* rather than LET:
(DEFINE-SETF-METHOD GETHASH (KEY HASH-TABLE)
(LET ((KEY-VAR (GENSYM))
(HASH-TABLE-VAR (GENSYM))
(STORE-VAR (GENSYM))
(HASH-INDEX-VAR (GENSYM)))
(VALUES (LIST KEY-VAR HASH-TABLE-VAR HASH-INDEX-VAR)
(LIST KEY HASH-TABLE `(HASH-TABLE-INDEX ,KEY-VAR HASH-TABLE-VAR))
(LIST STORE-VAR)
`(PUTHASH-INTERNAL ,KEY-VAR ,HASH-TABLE-VAR ,HASH-INDEX-VAR
,STORE-VAR)
`(GETHASH-INTERNAL ,KEY-VAR ,HASH-TABLE-VAR ,HASH-INDEX-VAR))))
∂29-Nov-83 0917 RPG &rest environments
∂27-Nov-83 1329 FAHLMAN@CMU-CS-C.ARPA &rest environments
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 27 Nov 83 13:29:48 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 27 Nov 83 16:28:56-EST
Date: Sun, 27 Nov 1983 16:28 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: MOON%SCRC-TENEX@MIT-ML.ARPA, bsg%SCRC-TENEX@MIT-ML.ARPA,
dlw%SCRC-TENEX@MIT-ML.ARPA, gsb@MIT-ML.ARPA, Guy.Steele@CMU-CS-A.ARPA,
rms@MIT-MC.ARPA, rpg@SU-AI.ARPA
Subject: &rest environments
In-reply-to: Msg of 26 Nov 1983 18:15-EST from MOON at SCRC-TENEX
I agree with what has been said earlier: those user-visible functions
that must explicitly manipulate an environment should pass that
environment around as a single object and not as a &rest arg.
In order to keep options open for various implementors, we should not
say anything about the structure of this environment object -- it must
simply be an implementation-dependent magic token that someone passes
out into user-land and that then gets passed on. Given that, it is
essential that this argument NOT be required in any function that the
user might call at top-level, including macroexpand and macroexpand-1.
If we want to make this a required arg in *eval and the various
mumble-hook functions, that's OK with me.
As others have pointed out, a change in the handling of ENV at this late
date is not the sort of change that will send tremors through much of
the user community -- at worst, we will have to change our interpreter
file and a couple of lines in the debuggerer.
-- Scott
∂29-Nov-83 0918 RPG Re: Macrolet
∂28-Nov-83 0004 @MIT-MC:RMS%MIT-OZ@MIT-MC Re: Macrolet
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Nov 83 00:04:40 PST
Date: Mon 28 Nov 83 03:04:23-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: Macrolet
To: RPG@SU-AI.ARPA
cc: steele@CMU-CS-C.ARPA, moon%scrc-tenex@MIT-MC, dlw%scrc-tenex@MIT-MC,
bsg%scrc-tenex@MIT-MC, fahlman@CMU-CS-C.ARPA,
"#COMMON.MSG[COM,LSP]"@SU-AI.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI>" of Thu 24 Nov 83 15:09:00-EST
Users have asked me in the past how to do what MACROLET does.
(There was no such clean way then.) So I think MACROLET is worth having.
Of there are unclear cases, it may be best to just say in the manual
that the results of MACROLET is undefined unless certain conditions are met.
These conditions could be chosen to include all the simple things for which
MACROLET was intended and exclude all the weird interactions.
If, later, someone figures out good extensions to the MACROLET feature
that make those weird cases be handled well, a future version of the manual
can tell people so.
-------
∂29-Nov-83 0921 RPG $rest environments
∂28-Nov-83 0028 @MIT-MC:RMS%MIT-OZ@MIT-MC $rest environments
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Nov 83 00:28:14 PST
Date: Mon 28 Nov 83 03:27:58-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: $rest environments
To: fahlman@CMU-CS-C.ARPA, steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA
I use two alists for the environment, and pass them as two args.
To use only one arg would require a lot of messy code, and I'm
not sure now that there are no screws in it. Please give me a
break and leave this alone.
-------
∂29-Nov-83 0921 RPG &rest environments
∂28-Nov-83 0054 @MIT-MC:RMS%MIT-OZ@MIT-MC &rest environments
Received: from MIT-MC by SU-AI with TCP/SMTP; 28 Nov 83 00:54:39 PST
Date: Mon 28 Nov 83 03:54:25-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: &rest environments
To: Guy.Steele@CMU-CS-A.ARPA, Fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA
Last summer I was told it was too late for certain changes, because
some people had already implemented things as specified.
&rest environments work perfectly well. There is no great problem
with them. I, and quite likely others, have implemented things
according to the present specification. So, following the principles
you were using last summer, it is several months too late to change
them now.
-------
∂29-Nov-83 0922 RPG MACROLET, environments, etc.
∂29-Nov-83 0521 STEELE@CMU-CS-C.ARPA MACROLET, environments, etc.
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 29 Nov 83 05:21:10 PST
Received: ID <STEELE@CMU-CS-C.ARPA>; Tue 29 Nov 83 08:23:11-EST
Date: Tue 29 Nov 83 08:23:10-EST
From: STEELE@CMU-CS-C.ARPA
Subject: MACROLET, environments, etc.
To: fahlman@CMU-CS-C.ARPA, dlw%scrc-tenex@MIT-MC.ARPA,
moon%scrc-tenex@MIT-MC.ARPA, rpg@SU-AI.ARPA, rms@MIT-MC.ARPA,
bsg%scrc-tenex@MIT-MC.ARPA
Given the substantial agreement of most of you folks, I have fixed
up macro expansion functions rpetty much as proposed in my note of
last week. DEFMACRO takes an additional lambda-list keyword
&ENVIRONMENT (as suggested by Moon, not &ENV); by extension, so do
MACROLET-defined macros (the syntax of MACROLET lambda-lists is by
definition the same as for DEFMACRO, as before). Also, environments
throughout the language are now single &optional arguments,
not &rest, defaulting to the null environment.
--Guy
-------
∂30-Nov-83 1040 Guy.Steele@CMU-CS-A Absolutely last changes to Common LISP
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 Nov 83 10:32:31 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 30 Nov 83 12:02:48 EST
Date: 30 Nov 83 1153 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Absolutely last changes to Common LISP
Greetings!
As you all know, the Common LISP technical specification was frozen
last Flag Day, June 14, 1983. This meant that no further proposals
for gratuitous changes could be seriously entertained if publication
was not to be delayed.
However, as I completed the work of editing in the changes that accumulated
before that date, some remaining serious difficulties, including outright
contradictions or gaps in the specifications, were uncovered. These
included:
(1) What lexical entities are visible to the bodies of macro definitions,
particularly those defined by MACROLET?
(2) The macro invocation mechanism was inadequate to support the MACROLET
feature at all (environment problems).
(3) The parsing of tokens was ill-specified with the introduction of the
new package syntax.
(4) The processing of end-of-file and the recursive-p argument to the
input functions was not consistent.
(5) The #+ and #- syntax was so underspecified as to be almost useless.
(6) Must lexical closures have their own data type?
(7) Certain functions added without much forethought to the implementation
consequences were giving implementors inordinate amounts of grief.
These included READ-BINARY-OBJECT, WRITE-BINARY-OBJECT, and
INIT-FILE-PATHNAME.
(8) The file name defaulting mechanism for LOAD was hopelessly inadequate
and incompatible for some operating systems.
(9) There was no good way to copy a structure.
(10) The treatment of newlines in the language was so ill-specified that
portability even of source code was endangered.
(11) EVAL-WHEN was underspecified.
Lest this process drag on forever, I feared to throw discussions wide
open again. Therefore I have made decisions, some rather arbitrary,
but all fairly well thought out, I hope. I did this in consultation
with some of the others on this mailing list, notably Fahlman, Gabriel,
Moon, Weinreb, Stallman, Greenberg, and Bawden, and am grateful for their
advice, but take all responsibility for the changes I have made.
I have tried very hard to stick to the rule that nothing be changed out
of a sense of aesthetics, but only to rectify contradictions, fill in
unexplained gaps, or radically increase usability. In two or three
cases I have simply eliminated a feature (such as READ-BINARY-OBJECT)
that has proved too difficult to implement as specified to be worth it.
At the end of this message is what I believe to be a complete list of
all changes (other than trivial corrections of typos or rephrasing of
prose for clarity) since the Excelsior Edition. What I hope for from
all of you is a sort of informal approval or ratification of these
changes. If you spot a gaffe, let me know pronto! I can handle only
fixes of things that have gone greatly awry, not new features or
changes just to pretty up the language. I am sorry to seem arbitrary
and hard-nosed, but Digital Press and I expect to typeset the book
within two or three weeks now. (The only thing blocking me is that I am
waiting for layout specs from their book designer.) So, please take a
couple of weeks to scan over these changes, and let me know if you see
any goofs. Also, if any change seems ill-motivated, and is not
adequately explained in the enclosed change list, please ask me, and
I will explain my reasons on this mailing list.
Another Dover-printed edition is being run off in small quantities at
CMU, and we will send out copies to serious implementors who need the
very latest specs. We (Fahlman and I) ask that people not actually
working on or testing an implementation wait until the published book
becomes available.
--Guy
----------------------------------------------------------------
Significant changes to the Common LISP Manual, Excelsior Edition.
"***" marks a significant language change that may have impact on code.
"---" marks an important clarification.
*** 16 Insert this text at the beginning of section 2.2 (characters),
in line with the decision that #\Return shall be a semi-standard
characters, and that #\Newline shall be the standard character for
representing line divisions. (It also serves to describe better the
charactrr set used by Common LISP.)
2.2. Characters
Characters are represented as data objects of type character. There are
two subtypes called standard-char and string-char.
2.2.1. Standard Characters
A character object can be notated by writing ``#\'' followed by the
character itself. For example, ``#\g'' means the character object for a
lower-case ``g''. This works well enough for ``printing characters''.
Non-printing characters have names, and can be notated by writing ``#\''
and then the name; for example, ``#\Space'' (or ``#\SPACE'' or ``#\space'',
for example) means the space character. The syntax for character names
after ``#\'' is the same as that for symbols. However, only character
names that are known to the particular implementation may be used.
Common LISP defines a ``standard character set'' (subtype standard-char)
for two purposes. Common LISP programs that are @i[written in the standard
character set can be read by any Common LISP implementation; and Common
LISP programs that @i[use only standard characters as data objects are most
likely to be portable. The Common LISP character set consists of a space
character #\Space, a newline character #\Newline, and these ninety-four
non-blank printing characters or their equivalents:
! " # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
@ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \ ] ↑ ←
` a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ~
It can be seen that the Common LISP standard character set is equivalent to
the 95 standard ASCII printing characters plus a newline character.
Nevertheless, Common LISP is designed to be relatively independent of the
ASCII character encoding. For example, the collating sequence is not
specified except to say that digits must be properly ordered, the
upper-case letters must be properly ordered, and the lower-case letters
must be properly ordered (see char< (page 186) for a precise
specification). Other character encodings, particularly EBCDIC, should be
easily accommodated (with a suitable mapping of printing characters).
The following characters are called semi-standard:
#\Backspace #\Tab #\Linefeed #\Page #\Return #\Rubout
Not all implementations of Common LISP need to support them, but those that
use the standard ASCII character set should support them, treating as
corresponding respectively to the ASCII characters BS (octal code 010), HT
(011), LF (012), FF (014), CR (015), and DEL (177). They are not members
of the subtype standard-char unless synonymous with one of the standard
characters specified above. For example, in a given implementation it
might be sensible for the implementor to define #\Linefeed or #\Return to
be synonymous with #\Newline, or #\Tab to be synonymous with #\Space.
2.2.2. Line Divisions
The treatment of line divisions is one of the most difficult issues in
designing portable software, simply because there is so little agreement
among operating systems. Some use a single character to delimit lines; the
recommended ASCII character for this purpose is the Line Feed character LF
(also called New Line, NL), but some systems use the Carriage return
character CR. Much more common is the two-character sequence CR followed
by LF. Frequently line divisions have no representation as a character,
but is implicit in the structuring of a file into records, each record
containing a line of text. A deck of punched cards has this structure, for
example.
Common LISP provides an abstract interface by requiring that there be a
single character, #\Newline, that within the language serves as a line
delimiter. (The language C has a similar requirement.) An implementation
of Common LISP must translate between this internal single-character
representation and whatever external representation(s) may be used.
Implementation note: How the character called #\Newline is represented
internally is not specified here, but it is strongly suggested that the
ASCII LF character be used in Common LISP implementations that use the
ASCII character encoding. The ASCII CR character is a workable, but in
most cases inferior, alternative.
The requirement that a line division be represented as a single character
has certain consequences. A character string (see section 2.5.2), written
in the middle of a program in such a way as to span more than one line,
must contain exactly one character to represent each line division.
Consider this code fragment:
(setq a-string "This string
contains
forty-two characters.")
Between ``g'' and ``c'' there must be exactly one character,
#\Newline; a two-character sequence, such as #\Return and then
#\Newline, is not acceptable, nor is the absence of a character.
The same is true between ``s'' and ``f''.
When the character #\Newline is written to an output file, the Common LISP
implementation must take the appropriate action to produce a line division.
This might involve writing out the next record, or translating #\Newline to
a CR/LF sequence.
Implementation note: If an implementation uses the ASCII character
encoding, uses the CR/LF sequence externally to delimit lines, uses LF to
represent #\Newline internally, and supports #\Return as a data object
corresponding to the ASCII character CR, the question arises as to what
action to take when the program writes out #\Return followed by #\Newline.
It should first be noted that #\Return is not a standard Common LISP
character, and the action to be taken when #\Return is written out is
therefore not defined by the Common LISP language. A plausible approach is
to buffer the #\Return character, and elide it if and only if the next
character if #\Newline. Another plausible approach is simply to ignore the
difficulty, and declare that writing #\Return and then #\Newline results in
the sequence CR/CR/LF in the output.
2.2.3. Non-Standard Characters
Any implementation may provide additional characters, whether printing
characters or named characters. Some plausible examples:
#\π (pi) #\Break #\Home-Up #\Escape
The use of such characters may render Common LISP programs non-portable.
2.2.4. Character Attributes
Every object of type character, etc.
--- 25 Added notes indicating the rationale behind defining integer and
ratio to be disjoint subtypes of rational, rather than together forming
an exhaustive partition of rational. The intent is to allow implementations
to experiment with extensions, such as adding positive and negative infinity,
in a compatible manner. Similarly for the relationship of fixnum and bignum
to integer. Note that if one were to add positive and negative infinity,
they would be of some type, say infinities, which would be a subtype of
integer, say, and therefore of rational, but not a subtype of common.
--- 26 Added a clarification about implementations unilaterally adding
subtypes to the type common. This is in apparent conflict with the
specification that any type created by defstruct is in common, because
implmentations may (and frequently will) define new
implementation-dependent data types via defstruct. I have added text
saying that types created *by the user* via defstruct become subtypes of
common. Is this spec acceptable?
--- 29 Augment implementation note to say that Common LISP is carefully
designed to permit either deep or shallow binding of special variables,
but the choice has implications for extensions to multiprocessing.
*** 39 Previously the value returned by deftype was not defined. Specify
explicitly that it returns the name of the type defined (by analogy with
defun).
--- 45 Add eval-when to the table of special forms.
--- 47 Add this clarification at the end of the first paragraph of
section 5.2 (Functions):
Note that symbols and lambda-expressions are treated as *names* of
functions in these two contexts. This should be distinguished from the
treatment of symbols and lambda-expressions as *function objects*, objects
that satisfy the predicate functionp, as when giving such an object to
apply or funcall to be invoked.
--- 50 Clarify that &aux bindings are like let*, not let.
--- 53 Specify that it is an error to use defun to redefine a special form.
*** 54 Previously the value returned by defvar, defparameter, and
defconstant was not defined. Specify explicitly that each of these
returns the name of the variable or constant defined (by analogy
with defun).
--- 55 eval-when is a special form, not a function.
*** 55 Add this clarification to the description of eval-when:
The eval-when construct may be more precisely understood in terms of a
model of how the compiler processes forms in a file to be compiled.
Successive forms are read from the file using the function read. These
top-level forms are normally processed in what we shall call
not-compile-time mode. There is another mode called compile-time-too
mode. The eval-when special form controls which of these two modes to
use.
Every form processed as follows:
* If the form is an eval-when form:
+ If the situation load is specified:
- If the situation compile is also specified, or if the current
processing mode is compile-time-too and the situation eval is also
specified, then process each of the forms in the body in
compile-time-too mode.
- Otherwise, process each of the forms in the body in
not-compile-time mode.
+ If the situation load is not specified:
- If the situation compile is also specified, or if the current
processing mode is compile-time-too and the situation eval is also
specified, then evaluate each of the forms in the body in the
compiler's executing environment.
- Otherwise, ignore the eval-when form entirely.
* If the form is not an eval-when form, then do two things. First,
if the current processing mode is compile-time-too mode, then
evaluate the form in the compiler's executing environment.
Second, perform normal compiler processing of the form (compiling
functions defined by defun forms, and so on).
*** 61 Add this clarification of functionp:
The predicate functionp is always true of symbols, lists whose car is the
symbol lambda, any value returned by the function special form, and any
values returned by the function compile when the first argument is nil.
*** 62 Add clarification under eql to the effect that (eql 0.0 -0.0) is
false iff the implementation supports 0.0 and -0.0 as distinct values.
*** 62 Add clarification under eql that two complex numbers are eql iff
their real and imginary parts respectively compare eql. So
(eql #C(5.0 4.0) #C(5 4)) is false, but (eql #C(5.0 4.0) #C(5.0 4.0)) is true.
Also, note that (eql #C(5.0 0.0) 5.0) is false, but (eql #C(5 0) 5) is true,
because #C(5 0) is simplified to just 5 by the rule of complex
canonicalization.
*** 62 Add discussion under eq and eql to the effect that the compiler
is permitted to "collapse" constants in compiled code that are equal.
A constant is defined to be a self-evaluating form or one that appears
in a quote form. So, for example, (eq "Foo" "Foo") might be true if
it appeared in compiled code, but (eq "Foo" (copy-seq "Foo")) would always
be false.
--- 62 Add some explanatory text saying that eq is not necessarily true
even when both arguments are "the same thing" if the thing is a number or
character, and discussing the relationship between eq and eql.
--- 68 Add examples for the function special form to exhibit the behavior
of lexical scoping, especially in the presence of setq.
--- 68 Add some clarification to the function special form regarding when
two distinct evaluations of the same function form may produce eq
closures. The general rule is that the implementation is free to have
two distinct evaluations of the same function form produce identical (eq)
closures if it can prove that the two conceptually distinct resulting
closures must in fact be behaviorally identical with respect to
invocation. This is merely a permitted optimization; a perfectly valid
implementation is simply to have every distinct evaluation of a function
form produce a new closure object not eq to any other.
Also add this text:
Frequently a compiler can deduce that a closure in fact does not need to
close over any variables bindings. For example, in the code fragment
(mapcar (function (lambda (x) (+ x 2))) y)
the function (lambda (x) (+ x 2)) contains no references to any outside
entity. In this important special case the same ``closure'' may be used
as the value for all evaluations of the function special form, and indeed
this value need not be a closure object at all, but may be a simple
compiled function containing no environment information. (This is simply
a special case of the foregoing discussion, but is included as a hint to
implementors familiar with previous methods of implementing LISP. The
distinction between closures and other kinds of function is somewhat
pointless, actually, as Common LISP defines no particular representation
for closures and no way to distinguish between closures and non-closure
functions. All that matters is that the rules of lexical scoping be
obeyed.)
*** 69 In the description of symbol-function, change "an error occurs"
to "an error is signalled" for the case where there is no function
definition. Change the description of the case of invoking as a function
the result of symbol-function on the name of a macro or special form
from "signals an error" to "is an error". (This latter change makes
things significantly easier for the various LISP Machine implementors,
I am told.)
--- 69 Note that one may use setf of symbol-function on a name that
already has a definition as a function or macro, but that it is an
error to do this on the name of a special form.
*** 73 Add the function rest to the list of functions usable with setf.
--- 75 Clarify description of psetq:
... all of the assignments are performed in an unpredictable order.
(The unpredictability matters only if more than one ``place'' form
refers to the same place.)
*** 75 Tighten up a sloppy definition of shiftf: the prog1 form presented
as an approximation to shiftf is replaced by:
The effect of (shiftf place1 place2 ... placen newvalue)
is roughly equivalent to
(let ((var1 place1)
(var2 place2)
...
(varn placen))
(setf place1 var2)
(setf place2 var3)
...
(setf placen newvalue)
var1)
*** 80 Add this specification to the handling of the temporary variables
and value forms that result from a setf method:
The temporary variables will be bound to the values of the value forms as
if by let*; that is, the value forms will be evaluated in the order
given, and may refer to the values of earlier value forms by using the
corresponding variables.
*** 87 Declarations may *not* appear at the beginning of the body of a
compiler-let. Rationale: Because of the unorthodox handling by
compiler-let of its variable bindings, it would be complicated and
confusing to permit declarations that apparently referred to the
variables bound by compiler-let. Disallowing declarations eliminates the
problem.
*** 88 Add this specification for macrolet. The main point is that
macro expansion functions are closed in the global environment, not in
the lexical environment.
The names established by macrolet as names for macros are lexically
scoped.
Macros often must be expanded at ``compile time'' (more generally, at a
time before the program itself is executed), and so the run-time values
of variables are not available to macros defined by macrolet. The
precise rule is that the macro-expansion functions defined by macrolet
are defined in the global environment; lexically scoped entities that
would ordinarily be lexically apparent are not visible within the
expansion functions. However, lexcially scoped entities are visible
within the body of the macrolet form, and are visible to the code that
is the expansion of a macro call. The following example should make this
clear:
(defun foo (x flag)
(macrolet ((fudge (z)
;The parameters x and flag are not accessible
; at this point; a reference to flag would be to
; the global variable of that name.
`(if flag (* ,z ,z) ,z)))
;The parameters x and flag are accessible here.
(+ x (fudge x) (fudge (+ x 1)))))
The body of the macrolet becomes
(+ x (if flag (* x x) x)) (if flag (* (+ x 1) (+ x 1)) (+ x 1)))
after macro expansion. The occurrences of x and flag legitimately
refer to the parameters of the function foo, because those parameters are
visible at the site of the macro call which produced the expansion.
--- 90 Add this clarification for the case construct:
The keys in the keylists are not evaluated; literal key values
must appear in the keylists.
--- 91 Add this clarification for the typecase construct:
The "type" that appears in each clause is a type specifier; it is not
evaluated, but it a literal type specifier.
*** 111 One implementor has asked whether a Common LISP interpreter ought
not properly apply the compiler to every defun form as it is read
interactively, this being the only way to guarantee compiler-interpreter
compatibility! In particular, this would cause macro calls to be expanded
right away, at defun time, rather than when the function is invoked and
its body interpreted.
This "compiling interpreter" strategy has been used for other LISP dialects,
and has some advantages. In order not to rule it out entirely, the discussion
of macros has been adjusted as follows:
When a function is being compiled, any macros it contains are expanded at
compilation time. This means that a macro definition must be seen by the
compiler before the first use of the macro.
More generally, an implementation of Common LISP has great latitude in
deciding exactly when to expand macro calls within a program. For
example, it is acceptable for the @Funref[defun special form to expand
all macro calls within its body at the time the defun form is executed,
and record the fully expanded body as the body of the function being
defined. (An implementation might even choose always to compile
functions defined by defun, even when operating in an ``interpretive''
mode!)
Macros should be written in such a way as to depend as little as possible
on the execution environment to produce a correct expansion. To ensure
consistent behavior, it is best to ensure that all macro definitions are
available (to the interpreter, compiler, or whatever) before any code
containing calls to those macros is introduced.
In Common LISP, macros are not functions. In particular, macros cannot
be used as functional arguments to such functions as apply, funcall, or
map; in such situations, the list representing the ``original macro
call'' does not exist, and cannot exist, because in some sense the
arguments have already been evaluated.
--- 112 Note that one may use setf of macro-function on a name that
already has a definition as a function or macro, but that it is an
error to do this on the name of a special form.
--- 112 Specify that defmacro may be used to redefine a macro or function,
but that it is an error to use defmacro to redefine a special form.
*** 112 Previously the value returned by defmacro was not defined.
Specify explicitly that it returns the name of the macro defined
(by analogy with defun).
*** 112 defmacro now allows another lambda-list keyword: &environment.
liek &rest and &whole, it requires exactly one following variable, which
is bound to the lexical environment in which the macro call occurred.
This may not be a complete lexical environment; it should be used only
with macroexpand for the sake of any local macro (macrolet) definitions
it may contain.
*** 112 Clarification of defmacro:
The expander function is effectively defined in the global environment;
lexically scoped entities established outside the defmacro form that
would ordinarily be lexically apparent are not visible within the body of
the expansion function.
*** 116 The env argument to macroexpand and macroexpand-1 is now
&optional, not &rest.
*** 116 A macro expansion function now takes two arguments, not one.
The second is the lexical environment in which the macro call is to
be interpreted.
*** 117 Change specification for misplaced declarations from
"If a declaration is found anywhere else an error will be signalled."
to the following:
It is an error to attempt to evaluate a declaration. Those special forms
that permit declarations to appear perform explicit checks for their
presence.
Compatibility Note: In MacLISP, declare is a special form that does
nothing but return the symbol declare as its result. The interpreter
knows nothing about declarations, but just blindly evaluates them,
effectively ignoring them. The MacLISP compiler recognizes declarations,
but processes them simply by evaluating the subforms of the declaration
in the compilation context. In Common LISP it is important that both the
interpreter and compiler recognize declarations (especially special
declarations) and treat them consistently, and so the rules about the
structure and use of declarations have been made considerably more
stringent.
--- 121 Correction of a bug: the compiler is *not* to ignore notinline
declarations. Calls to functions declared notinline (even car, cdr, and
eq) must be compiled as out-of-line function calls. The compiler is
always free to ignore inline declarations, however.
--- 126 Add this clarification to get, correlated with the change to gethash
on page 225. A similar but shorter clarification is added for getf.
The default argument may be specified to get in this context; it is
ignored by setf, but may be useful in such macros as push that are
related to setf:
(push item (get sym 'token-stack '(initial-item)))
means the approximately the same as
(setf (get sym 'token-stack '(initial-item))
(cons item (get sym 'token-stack '(initial-item))))
which in turn would be treated as simply
(setf (get sym 'token-stack)
(cons item (get sym 'token-stack '(initial-item))))
*** 128 Eliminate the function samepnamep. It is to all intents and
purposes identical to a subset of string=. It was earlier retained
because there was some argument over whether string functions should
accept symbols as arguments. They do, and so samepnamep should
have gone away and didn't because I failed to garbage-collect it.
*** 130 Change keywordp to accept any Lisp object, not just symbols. It
is true if the argument is a symbol and that symbol is a keyword.
--- 130 Add this note about gensym:
Compatibility note: In earlier versions of LISP, such as MacLISP and
InterLISP, the print name of a gensym was of fixed length, consisting of
a single letter and a fixed-length decimal representation with leading
zeros if necessary, for example ``G0007''. This convention was motivated
by an implementation consideration, namely that the name should fit into
a single machine word, allowing a quick and clever implementation. Such
considerations are less relevant in Common LISP. The consistent use of a
variable-length prefix can make it easier for the programmer, when
debugging, to determine what code generated a particular symbol. The
elimination of the fixed-length decimal representation prevents the same
name from being used twice unless the counter is explicitly reset.
*** 134 Here, and everywhere in the manual, infix "#:" becomes "::".
So foo::bar means the (possibly internal) symbol bar in package foo.
"#:" is still used as a prefix for gensymmed symbols.
--- 14 Eliminate all references to "B" and "b" as exponent markers.
A more general theory of this is elucidated in the changes for page 268.
*** 153 Add clarification that (zerop -0.0) is true, and (minusp -0.0) is
false, regardless of whether the implementation supports 0.0 and -0.0 as
distinct values. To distinguish -0.0 from 0.0, float-sign should be used.
*** 154 Add clarification and examples for = to the effect that
mixed-type comparisons are permitted, and (= 0.0 -0.0) is always true
regardless of whether the implementation supports 0.0 and -0.0 as
distinct values.
*** 154 Add clarification that complex numbers are = iff their
real and imaginary parts are respectively =. Note that one may use =
to compare a complex to a non-complex number; (= #C(5.0 0.0) 5.0) is true.
*** 155 Combine entries for max and min. Add remarks to the effect that
if several arguments tie for largest or smallest, then any one of them
may be returned; for example, the result of (min 3 1 1.0s0 1.0d0) could
be any one of 1, 1.0s0, or 1.0d0. The general rule is that you must
pick one of the arguments of largest (smallest) value, and then either
return it as is or apply the rules of floating-point contagion (taking
*all* the arguments into consideration for contagion purposes).
--- 158 A clarification to be inserted just before the implementation note
in section 12.4:
If the arguments are all rational but the result cannot be expressed as a
rational number, then a single-precision floating-point approximation is
always returned.
The rules of floating-point contagion and complex contagion are
effectively obeyed by all the functions in this section except expt,
which treats some cases of rational exponents specially. When, possibly
after contagious conversion, all of the arguments are of the same
floating-point or complex floating-point type, then the result will be of
that same type unless otherwise noted.
--- 159 Add example showing that log of a negative non-complex will
produce a complex result.
--- 160 Clarify definitions of asin, acos, and atan by copying the
formulae from page 163.
--- 179 Clarify that for most-positive-short-float, the value is that
short floating-point number clostest to *but not equal to* positive
infinity. (The amplification is necessary because some floating-point
encodings provide explicit representations for infinities.) Similar
clarification is made for the other three constants in that group.
--- 180 Reword the definition of xxx-float-epsilon to make clear that
the test expression given is intended to be executable code and not
a mathematical abstraction as other expressions in the chapter
are intended to be:
These constants have as value, for each floating-point format,
the smallest positive floating-point number e of that format such that
the expression
(not (= (float 1 e) (+ (float 1 e) e)))
is true when actually evaluated.
The xxx-float-negative-epsilon constants are similarly clarified.
--- 183 Add note at front of characters chapter paralleling that at front
of numbers chapter, noting that eq doesn't work on characters.
--- 184 Change the restriction concerning font 0 to the following
less stringent requirement:
Programs may assume that graphic characters of font 0 are all of the same
width when printed, for example for purposes of columnar formatting.
(This does not prohibit the use of a variable-pitch font as font 0, but
merely implies that every implementation of Common LISP must provide
*some* mode of operation in which font 0 is a fixed-pitch font.)
Portable programs should assume that, in general, non-graphic characters
and characters of other fonts may be of varying widths.
*** 185 Change the description of alphanumericp from
(alphanumericp x) <=> (or (alpha-char-p x) (digit-char-p x))
to
(alphanumericp x) <=> (or (alpha-char-p x) (not (null (digit-char-p x))))
The point is that alphanumericp returns t or nil, always, even though
digit-char-p sometimes returns an integer.
*** 189 Eliminate the "bits" argument to digit-char (but retain the
"font" argument). The bits argument is useless because no digit can have
non-zero bits. (Every digit is graphic, and no graphic has non-zero
bits. Thanks to Walter van Roggen for catching this implication.)
*** 190 The argument to name-char and the result of char-name are
supposed to be strings, not symbols. That symbols are mentioned
is a horrible accident of history. Now char-name returns a string.
The spec for name-char is:
The argument name must be an object coerceable to a string as if by the
function string. If the name is the same as the name of a character
object (as determined by string-equal), that object is returned;
otherwise nil is returned.
--- 191 Specify explicitly that it is an error to give to char-bit the
name of a bit not supported by the implementation.
--- 199 Specify for the replace function that if the two sequences are
not eq, but happen to overlap because of sharing of list structure or
array displacement, then the values stored into the specified subsequence
of sequence1 are unpredictable. (The case where the two sequences are
eq is still required to "work" when there is overlap.)
--- 199 Clarification: specify for the remove and delete functions that
elements not removed or deleted occur in the same order in the result
that they did in the argument.
*** 210 Add a note that the function rest may be used with setf.
*** 213 The macro pushnew takes keywords :test, :test-not, and :key,
as for the function adjoin.
*** 213 The pushnew macro returns the new contents of the place,
not nil. (The prose and the examples were in conflict. The prose
is hereby declared to be wrong.)
*** 215 Change argument order for subst-if and subst-if-not to be
consistent with substitute-if and substitute-if-not. Similarly for
nsubst-if and nsubst-if-not. This is an old bug that just never was
fixed until now.
*** 216 Specify that sublis can substitute for any object, not just symbols,
and checks both subtrees and leaves. In effect, it is just several
simultaneous and parallel subst operations. Example:
(sublis '(((+ x y) . (- x y)) ((- x y) . (+ x y)))
'(* (/ (+ x y) (+ x p)) (- x y))
:test #'equal)
=> (* (/ (- x y) (+ x p)) (+ x y))
*** 216 In the sample definition of subst, the expression
(and (eq a (car tree)) (eq d (cdr tree)))
should be
(and (eql a (car tree)) (eql d (cdr tree)))
--- 218 Add this clarification to the description of the function union:
In general, the test may be any predicate, and the union operation may be
described as follows: for all possible ordered pairs consisting of one
element from list1 and one element from list2, the test is used
to determine whether they ``match''. For every matching pair, at least
one of the two elements of the pair will be in the result. Moreover, any
element from either list that matches no element of the other will appear
in the result. All this is very general, but probably not particularly
useful unless the test is an equivalence relation.
The :test-not argument can be useful when the test function is the
logical negation of an equivalence test. A good example of this is the
function mismatch, which is logically inverted so that possibly useful
information can be returned if the arguments do not match. This additional
``useful information'' is discarded in the following example; mismatch
is used purely as a predicate.
(union '(#(a b) #(5 0 6) #(f 3))
'(#(5 0 6) (a b) #(g h))
:test-not
#'mismatch)
@EV (#(a b) #(5 0 6) #(f 3) #(g h)) ;One possible result.
@EV ((a b) #(f 3) #(5 0 6) #(g h)) ;Another possible result.
Using :test-not #'mismatch differs from using :test #'equalp, for
example, because mismatch will determine that #(a b) and (a b) are the
same, while equalp would regard them as not the same.
--- 218 Add this clarification to the description of the function intersection:
In general, the test may be any predicate, and the intersection operation
may be described as follows. For all possible ordered pairs consisting
of one element from list1 and one element from list2, the test is used to
determine whether they ``match''. For every matching pair, at exactly
one of the two elements of the pair will be put in the result. No
element from either list appears in the result that does not match an
element from the other list. All this is very general, but probably not
particularly useful unless the test is an equivalence relation.
--- 218 Add this clarification to the description of set-difference:
There is no guarantee that the order of elements in the result will
reflect the ordering of the arguments in any particular way.
The implementation is therefore free to use any of a variety of strategies.
In general, the test may be any predicate, and the set difference
operation may be described as follows. For all possible ordered pairs
consisting of one element from list1 and one element from list2, the test
is used to determine whether they ``match''. An element of list1 appears
in the result if and only if it does not match any element of list2.
This is very general, and permits interesting applications. For example,
one can remove from a list of strings all those strings containing one of
a given list characters:
;; Remove all flavor names that contain "c" or "w".
(set-difference '("strawberry" "chocolate" "banana"
"lemon" "pistachio" "rhubarb")
'(#\c #\w)
:test
#'(lambda (s c) (find c s)))
@EV ("banana" "rhubarb" "lemon") ;One possible ordering.
--- 218 Add this clarification to the description of set-exclusive-or:
There is no guarantee that the order of elements in the result will
reflect the ordering of the arguments in any particular way.
The implementation is therefore free to use any of a variety of strategies.
In general, the test may be any predicate, and the set-exclusive-or operation
may be described as follows. For all possible ordered pairs consisting of
one element from list1 and one element from list2, the test is
used to determine whether they ``match''. The result contains precisely
those elements of list1 and list2 that appear in no matching pair.
--- 219 Clarify the definition of subsetp in this way:
subsetp is a predicate that is true if every element of list1
appears in (``matches'' some element of) list2, and false otherwise.
*** 225 Change it so that the default argument may be given to gethash
in a setf context. I missed the fact that this is extremely important
when using setf-based macros such as incf. The new description is:
setf may be used with gethash to make new entries in a hash
table. If an entry with the specified key already exists, it is
removed before the new entry is added. The default argument may be
specified to gethash in this context; it is ignored by setf, but
may be useful in such macros as incf that are related to setf:
(incf (gethash a-key table 0))
means the approximately the same as
(setf (gethash a-key table 0) (+ (gethash a-key table 0) 1))
which in turn would be treated as simply
(setf (gethash a-key table) (+ (gethash a-key table 0) 1))
--- 229 Specify that it is an error to make an array A be displaced to array
B if the element-types of the two arrays are not the same.
--- 230 Specify for the constant array-total-size-limit that the limit
imposed by the implementation may vary according to the element-type of
the array; in this case the value of array-total-size-limit will be
the smallest of these individual limits.
--- 230 Add a note under the function aref about the use of setf and apply:
Under some circumstances it is desirable to write code that will extract
an element from an array ``a'' given a list ``z'' of the indices, in such
a way that the code works regardless of the rank of the array. This is
easily using apply:
(apply #'aref a z)
(The length of the list must of course equal the rank of the array.)
This construction may be used with setf to alter the element so selected
to some new value ``w'':
(setf (apply #'aref a z) w)
(One point of this is that every Common LISP implementation must
make sure that setf of aref is implemented in such a way that the
interaction of setf with apply manages to win as shown here.)
*** 232 Add a new predicate adjustable-array-p, which takes one
argument that must be an array, and is true if the array is adjustable.
*** 235 Necessary change to vector-push-extend; it now might return nil:
If, however, the vector is not adjustable, then vector-push-extend
simply ``fails'' the way vector-push does, and returns nil.
*** 241 For the function string, add that if the argument is a string
character (a character of type string-char), then a string containing
that one character is returned. (An error is signalled if the argument
is a character that will not fit in a string.)
--- 244 A clarification of the defstruct ship example; one additional
effect is:
The #S syntax can be used to read instances of ship structures, and a
printer function is provided for printing out ship structures. For
example, the value of the variable ship2 shown above might be printed as
#S(ship x-position 0 y-position 0 x-velocity nil
y-velocity nil mass 170000.0)
*** 245 Previously the value returned by defstruct was not defined.
Specify explicitly that it returns the name of the structure defined
(by analogy with defun).
*** 245 A serious typo in defstruct: it may take zero slot-descriptions.
The header should have "{slot-description}*", not "{slot-description}+".
--- 247 Clarify that the type specified to the :type slot-option must
be a valid type specifier.
*** 248 Eliminate the :unnamed option to defstruct. If the :type option
is not specified, the structure is always named, and the structure name
becomes a valid type specifier acceptable to typep. If the :type option
is specified, then the structure name does not become a type specifier,
and the presence or absence of the :named defstruct option determines
whether or not a component is allocated to hold the structure name.
(There was a fair amount of confusion regarding the interaction between
the :type option and several other features. Elimination of :unnamed
does not remove any functionality, but allows a simpler exposition
of what's going on, because fewer combinations of defstruct options
need to be described as illegal!)
*** 249 Specify that a predicate function may be defined if no
:type option is specified, or if both the :type and :named options
are specified. If :type is specified and :named is not, then the
:predicate option must be either unspecified or of value nil.
--- 249 Clarify that a given defstruct declaration may contain at most
one :include option; that if the structure being defined has no :type
option then an included structure must not have had a :type option; and
that if the structure being defined does have :type option then an
included structure must have had a :type option specifying the same
representation type.
--- 250 Clarify that the :print-function option may in fact only be
specified if the :type option is not specified.
--- 250 Clarify that the :initial-offset option may in fact only be
specified if the :type option is also specified.
--- 250 Reorder the descriptions of the defstruct options so that
:type, :named, and :initial-offset immediately precede :eval-when.
*** 250 Add the following additional specification for the defstruct
:print-function option:
If the :print-function option is not specified and the :type
option also not specified, then a default printing function is
provided for the structure that will print out all its slots
using #S syntax (see section SHARP-SIGN-MACRO-CHARACTER-SECTION).
*** 250 Eliminate the :eval-when option to defstruct.
*** 250 A bug in the description of the :print-function option to
defstruct: the argument is not evaluated. Replace the second sentence
with this version:
The argument to the :print-function option should be a function of three
arguments, in a form acceptable to the function special form, to be used
to print structures of this type.
For example, one may write (:print-function (lambda (x y z) ...))
or (:print-function my-printer), not (:print-function #'my-printer).
--- 251 Add a new section 19.7 explaining, with examples, the
ramifications of the :type, :named, and :initial-offset options to
defstruct, and the interaction of the :include and :type options.
*** 254 *eval is gone. It didn't make a lot of sense in the white pages.
The only thing that could use it effectively is a hook function, and a
hook function can just as well confine itself to using evalhook and
applyhook with appropriate arguments.
*** 257 The variables *, **, and ***, and /, //, and /// are always
in lock step with each other, but not necessarily with +, ++, and +++.
If the computation is aborted, then * and friends are not updated;
they are updated only if the printing of values commences (and stay
updated even if printing is aborted once begun).
*** 260 Note that the initial value of *debug-io*, as well as of
*standard-input*, *standard-output*, *error-output*, *trace-output*, and
*query-io*, is initially a synonym stream to *terminal-io*.
*** 261 Clarification of make-broadcast-stream:
If no streams are given as arguments, then the result is a ``bit sink'';
all output is discarded, and every operation results in nil.
--- 262 Flush line-length argument to make-string-output-stream. It
makes no sense, as the meaning of the line-length of a stream is nowhere
defined in the manual.
*** 262 Clarification of with-open-stream: ... the forms of the body are
executed as an implicit @f[progn]; the results of evaluating the last
form are returned as the value of the @f[with-open-stream] form.
--- 263 Clarify that the argument of input-stream-p, output-stream-p,
stream-element-type, and close must be a stream.
*** 263 Clarification of with-output-to-string: it is as
if vector-push-extend were used, not vector-push.
--- 266 Be more specific about when lower-case letters are converted to
upper case within tokens and when they are not. (They are converted
except when read under the influence of an escape character.)
*** 266 Completely rewrite section 22.1.1, which describes how the reader
algorithm works, and particularly how tokens are scanned. A fifth kind
of character is introduced in addition to whitespace, constituent, macro,
and escape: the multiple escape (and escape is renamed to single escape).
The character "|" is initially of type multiple escape rather than being
a macro character. When you see a multiple escape (think "|") character,
whether initially or in the middle of a token, then all following macro,
constituent, and whitespace characters are treated as alphabetic (and
lower-case characters are not converted to upper case); a single escape
character causes the next character to be treated as alphabetic; and end
of file signals an error. Seeing another multiple escape character
causes you to revert to the normal token-scanning mode, where letters are
converted to upper case, and scanning may be terminated by a whitespace,
terminating macro character, or end of file.
To put it more simply, when scanning a token, a vertical bar toggles
whether you are in vertical-bar mode or not, but never terminates token
scanning in and of itself.
This has the consequence that "|foo|bar|baz|", which MacLISP would treat
as three distinct tokens "|foo|", "bar", and "|baz|", will be treated by
Common LISP as a single token equivalent to "|fooBARbaz|". The
motivation for all this is that "|foo|:|bar|" also gets treated as a
single token, and because the colon is not within vertical bars it may be
taken as a package marker. (By contrast, "|foo:bar|" simply means, as
always, a symbol whose name contains seven characters, six being
lower-case letters and the middle one being a colon.)
Note that the single escape character "\" continues to be "stronger"
than the multiple escape character "|"; to get a "\" or "|" into a token,
you must precede it with "\", even when between vertical bars.
*** 268 Kill the first paragraph of section 22.1.2, and replace with the
following paragraphs. (Also kill the paragraph before *read-base* on
page 269.)
When an extended token is read, it is interpreted as a number or symbol.
The characters of the extended token may serve various syntactic
functions as shown in Table 22-3, but it must be remembered that any
character included in a token under the control of an escape character is
treated as alphabetic rather than according to the attributes shown in
the table. One consequence of this rule is that a whitespace, macro, or
escape character will always be treated as alphabetic within an extended
token, because such a character cannot be included in an extended token
except under the control of an escape character.
To allow for extensions to the syntax of numbers, a syntax for potential
numbers is defined in Common LISP that is more general than the actual
syntax for numbers. Any token that is not a potential number and does
not consist entirely of dots will always be taken to be a symbol, now and
in the future; programs may rely on this fact. Any token that is a
potential number but does not fit the actual number syntax defined below
is a reserved token, and has an implementation-dependent interpretation;
an implementation may signal an error, quietly treat the token as a
symbol, or take some other action. Programmers should avoid the use of
such reserved tokens. (A symbol whose name looks like a reserved token
can always be written using one or more escape characters.)
A token is a potential number if it satisfies the following requirements:
- It consists entirely of digits, signs (``+'' or ``-''), ratio markers
(``/''), decimal points (``.''), extension characters (``↑'' or ``←''),
and number markers. (A number marker is a letter. Whether a letter may
be treated as a number marker depends on context, but no letter that is
adjacent to another letter may ever be treated as a number marker.
Floating-point exponent markers are instances of number markers.)
- It contains at least one digit. (Letters may be considered to be digits,
depending on the value of *read-base*, but only in tokens containing no
decimal points.)
- It begins with a digit, sign, decimal point, or extension character.
- It does not end with a sign.
As examples, the following tokens are potential numbers, but are not
actually numbers as defined below, and so are reserved tokens. (They do
indicate some interesting possibilities for future extensions.)
1b5000 777777q 1.7J -3/4+6.7J 12/25/83
27↑19 3↑4/5 6//7 3.1.2.6 ↑-43↑
3.141←592←653←589←793←238←4 -3.7+2.6i-6.17j+19.6k
The following tokens are not potential numbers, but are always
treated as symbols:
/ /5 + 1+ 1-
foo+ ab.cd ← ↑ ↑/-
The following tokens are potential numbers if the value of *read-base* is
16 (an abnormal situation), but are always treated as symbols if the
value of *read-base* is 10 (the usual value):
bad-face 25-dec-83 a/b fad←cafe f↑
It is possible for there to be an ambiguity as to whether a letter should
be treated as a digit or as a number marker. In such a case the letter
is always treated as a digit rather than as a number marker.
Note that the printed representation for a potential number may not
contain any escape characters. An escape character robs the following
character of all syntactic qualities, forcing it to be strictly
alphabetic, and so unsuitable for use in a potential number. For
example, all of the following representations are interpreted as symbols,
not numbers:
\256 25\64 1.0\E6 |100| 3\.14159 |3/4| 3\/4
In each case, removing the escape characters would allow the token to be
treated as a number.
If a potential number can in fact be interpreted as a number according to
the BNF syntax in Table 22-2, then a number object of the appropriate
type is constructed and returned. It should be noted that in a given
implementation it may be that not all tokens conforming to the actual
syntax for numbers can actually be converted into number objects. For
example, specifying too large or too small an exponent for a
floating-point number may make the number impossible to represent in the
implementation. Similarly, a ratio with denominator zero (such as
``-35/000'') cannot be represented in any implementation. In any such
circumstance where a token with the syntax of a number cannot be
converted to an internal number object, an error is signalled. (On the
other hand, an error must not be signalled for specifying too many
significant digits for a floating-point number; an appropriately
truncated or rounded value should be produced.)
--- 269 Add a long paragraph under *read-base* explaining to the user
the dangers of setting *read-base* to a value higher than 10.
*** 269 New explanation of the interpretation of package markers:
In all other cases the token is construed to be the name of a symbol. If
there are any package markers (colons) in the token, they divide the
token into pieces used to control the lookup and creation of the symbol.
If there is a single package marker, and it occurs at the beginning of
the token, then the token is interpreted as a keyword, that is, a symbol
in the keyword package. The part of the token after the package marker
must not have the syntax of a number.
If there is a single package marker not at the beginning or end of the
token, then it divides the token into two parts. The first part
specifies a package; the second part is the name of an external symbol
available in that package. Neither of the two parts may have the syntax
of a number.
If there is are two adjacent package markers not at the beginning or end
of the token, then they divide the token into two parts. The first part
specifies a package; the second part is the name of a symbol within that
package (possibly an internal symbol). Neither of the two parts may have
the syntax of a number.
If a symbol token contains no package markers, then the entire token is
the name of the symbol. The symbol is looked up in the default package;
see *package*.
All other patterns of package markers, including the cases where there
are more than two package markers, or where a package marker appears at
the end of the token, presently do not mean anything in Common LISP; see
chapter 11. It is therefore currently an error to use such patterns in a
Common LISP program. The valid patterns for tokens may be summarized as
follows:
nnnnn a number
xxxxx a symbol in the current package
:xxxxx a symbol in the keyword package
ppppp:xxxxx an external symbol in the ppppp package
ppppp::xxxxx a (possibly internal) symbol in the ppppp package
where nnnnn has the syntax of a number, and xxxxx and ppppp do not have
the syntax of a number.
*** 269 Add a new variable *read-suppress*, that embodies the mechanism
needed to make #+ and #- work:
*read-suppress* [Variable]
When the value of *read-suppress* is nil, the LISP reader operates
normally. When it is not nil, then most of the interesting operations of
the reader are suppressed; input characters are parsed, but much of what
is read is not interpreted.
The primary purpose of *read-suppress* is to support the operation of the
read-time conditional constructs ``#+'' and ''#-'' (see section 22.1.4).
It is important for these constructs to be able to skip over the printed
representation of a LISP expression despite the possibility that the
syntax of the skipped expression may not be entirely legal for the
current implementation; this is because a primary application of ``#+''
and ``#-'' is to allow the same program to be shared among several LISP
implementations despite small incompatibilities of syntax.)
A non-nil value of *read-suppress* has the following specific effects on
the Common LISP reader:
- All extended tokens are completely uninterpreted. It matters not whether
the token looks like a number, much less like a valid number; the pattern
of package markers also does not matter. An extended token is simply
discarded and treated as if it were nil; that is, reading an extended
token when *read-suppress* is non-nil simply returns nil. (One
consequence of this is that the error concerning improper dotted-list
syntax will not be signalled.)
- Any sharp-sign macro construction that requires, permits, or disallows an
infix numerical argument, such as ``#nR'', will not enforce any
constraint on the presence, absence, or value of such an argument.
- The ``#\'' construction always produces the value nil. It will not
signal an error even if an unknown character name is seen.
- Each of the ``#B'', ``#O'', ``#X'', and ``#R'' constructions always scans
over a following token and produces the value nil. It will not signal an
error even if the token does not have the syntax of a rational number.
- The ``#*'' construction always scans over a following token and produces
the value nil. It will not signal an error even if the token does not
consist solely of the characters ``0'' and ``1''.
- Each of the ``#.'' and ``#,'' constructions reads the following form (in
suppressed mode, of course), but does not evaluate it. The form is
discarded and nil is produced.
- Each of the ``#A'', ``#S'', and ``#:'' constructions reads the following
form (in suppressed mode, of course), but does not interpret it in any
way; it need not even be a list in the case of ``#S'', or a symbol in the
case of ``#:''. The form is discarded and nil is produced.
- The ``#='' construction is totally ignored. It does not read a following
form. It produces no object, but is treated as whitespace.
- The ``##'' construction always produces nil.
- The ``#+'' and ``#-'' constructions skip over one form (the feature
descriptor) but not over a second form (the conditionalized form).
Neither produces an object; both are treated as whitespace.
Note that, no matter what the value of *read-suppress*, parentheses still
continue to delimit (and construct) lists; the ``#('' construction
continues to delimit vectors; and comments, strings, and the quote and
backquote constructions continue to be interpreted properly.
Furthermore, such situations as ``')'', ``#<'',``#)'', and ``#<space>'',
continue to signal errors.
In some cases it may be appropriate for a user-written macro-character
definition to check the value of *read-suppress* and avoid certain
computations or side effects if its value is not nil.
--- 271 Add these examples of the handling of dots:
(a . b) ;A dotted pair of a and b.
(a.b) ;A list of one element, the symbol named ``a.b''.
(a. b) ;A list of two elements ``a.'' and ``b''.
(a .b) ;A list of two elements ``a'' and ``.b''.
(a \. b) ;A list of three elements ''a'', ``.'', and ``b''.
(a |.| b) ;A list of three elements ''a'', ``.'', and ``b''.
(a \... b) ;A list of three elements ''a'', ``...'', and ``b''.
(a |...| b) ;A list of three elements ''a'', ``...'', and ``b''.
(a b . c) ;A dotted list of a and b with c at the end.
.iot ;The symbol whose name is ``.iot''.
(. b) ;Illegal; an error is signalled.
(a .) ;Illegal; an error is signalled.
(a .. b) ;Illegal; an error is signalled.
(a . . b) ;Illegal; an error is signalled.
(a b c ...) ;Illegal; an error is signalled.
*** 272 Delete the paragraph on vertical bar as a macro character.
It is now a "multiple escape" character.
*** 277 Add a parenthetical remark to the effect that "#6()" is illegal:
If an unsigned decimal integer appears between the ``#'' and ``('', it
specifies explicitly the length of the vector. In that case, it is an
error if too many objects are specified before the closing ``)'', and if
too few are specified the last object (it is an error if there are none
in this case) is used to fill all remaining elements of the vector.
Add a similar remark about #*. If you want replication, you must
specify at least one element so that there is something to replicate.
(This is more robust than assuming NIL or 0. Note that "#0()" is
legtimate, because in that case there are not too few elements
specified.)
*** 278 A clarification of #S syntax:
Let cm stand for the name of this constructor macro;
then this syntax is equivalent to
#.(cm keyword1 'value1 keyword2 'value2 ...)
where each keywordj is the result of computing
(intern (string slotj) 'keyword)
(This computation is made so that one need not write a colon in front of
every slot name.)
*** 281 In the second sentence describing the function copy-readtable,
strike the words "unsupplied or", to remove a blatant contradiction. If
the from-readtable argument is unsupplied, it defaults to the current
readatble. If explicitly supplied but nil, it means the standard,
platonically ideal Common LISP readtable.
*** 284 Specification added for the printed representation of complex
numbers; this had accidentally been omitted. A complex number is printed
as "#C(", the printed representation of its real part, a space, the
printed representation of its imaginary part, and finally ")".
*** 284 Add a clarification of how the printer decides when a symbol
must be printed with backslash or vertical-bar syntax:
In particular, backslash or vertical-bar syntax is used when the name of
the symbol would be otherwise treated by the reader as a number. In
making this decision, it is assumed that the value of *print-base* being
used for printing would be used as the value of *read-base* used for
reading; the value of *read-base* at the time of printing is irrelevant.
For example, if the value of *print-base* were 16 when printing the
symbol ``face'', it would have to be printed as ``\FACE'' or ``\Face'' or
``|FACE|'', because the token ``face'' would be read as a hexadecimal
number (decimal value 64206) if *read-base* were 16.
--- 284 Change the first sentence under "Floating-point numbers" from
"Floating-point numbers are printed in one of two ways." to
"If the sign of the number (as determined by the function float-sign)
is negative, then a minus sign is printed. Then the magnitude is
printed in one of two ways."
--- 284 Clarify that a zero floating-point number is printed in fixed
format, not exponential format, despite being outside the range
10↑-3 to 10↑7.
*** 285 Clarify that *print-gensym* is operative only when *print-escape*
is not nil.
*** 286 Add this clarification to how objects are printed:
Common LISP does not specify a specific syntax for printing objects of
type pathname. However, every implementation must arrange to print a
pathname in such a way that, within the same implementation of Common
LISP, the function read can construct from the printed representation an
equivalent instance of the pathname object.
--- 286 Add this clarification to how objects are printed:
It is specifically and purposely *not* required that a Common LISP
implementation be able to print an object of type hash-table, readtable,
package, stream, or function in a way that can be read back in
successfully by read; the use of ``#<'' syntax is especially recommended
for the printing of such objects.
*** 286 Add this clarification of how arrays are printed (the reader
already handles it; it's just a matter of giving the printer permission
to produce it):
If the array is of a specialized type, containing bits or
string-characters, then the innermost lists generated by the algorithm
given above may instead be printed using bit-vector or string syntax,
provided that these innermost lists would not be subject to truncation by
prinlength. For example, a 3-by-2-by-4 array of string-characters that
would ordinary be printed as
#3A(((#\s #\t #\o #\p) (#\s #\p #\o #\t))
((#\p #\o #\s #\t) (#\p #\o #\t #\s))
((#\t #\o #\p #\s) (#\o #\p #\t #\s)))
may instead be printed more concisely as
#3A(("stop" "spot") ("post" "pots") ("tops" "opts"))
--- 287 Clarification: the initial value of @Var[print-pretty] is
implementation-dependent.
*** 289 Change spec for *print-array*: the initial value of
@Var[print-array] is implementation-dependent.
*** 291 The interaction between the recursive-p and eof-error-p arguments
has been greatly simplified. The action taken at end-of-file no longer ever
depends on the eof-error-p of the top-level call, and depends on recursive-p
only to the extent of determining which of two errors is signalled:
When end-of-file is encountered and the eof-error-p argument is
not nil, the kind of error that is signalled may depend on the
value of recursive-p. If recursive-p is not nil, then the
end-of-file may be deemed to have occurred within the middle of a
printed representation; if recursive-p is nil, then the
end-of-file is deemed to have occurred between objects rather than
within the middle of one.
--- 292 Amplify the discussion of read-delimited-list to make it clear
that it does not fiddle with the syntax of the argument character:
To be more precise, read-delimited-list looks ahead at each step for the
next non-whitespace character and peeks at it as if with peek-char. If
it is @i[char, then the character is consumed and the list of objects is
returned. If it is a constituent or escape character, then read is used
to read an object, which is added to the end of the list. If it is a
macro character, the associated macro function is called; if the function
returns a value, that value is added to the list. The peek-ahead process
is then repeated....
It is necessary here to give a definition to the character ``}'' as well
to prevent it from being a constituent. If the line
(set-macro-character #\} (get-macro-character #\) @nil))
shown above were not included, then the ``}'' in
#{p q z a}
would be considered a constituent character, part of the symbol named
``a}''. One could correct for this by putting a space before the ``}'',
but it is better simply to use the call to set-macro-character.
*** 296 The function read-binary-byte has been eliminated. It was not
well thought out and was giving implementors a great deal of grief. The
function read-byte is a primitive sufficient to write more complicated
things.
*** 297 All "write" functions except write-char return the first
argument. For consistency, change write-char to return its first
argument rather than nil.
*** 298 The function write-binary-byte has been eliminated. It was not
well thought out and was giving implementors a great deal of grief. The
function write-byte is a primitive sufficient to write more complicated
things.
*** 299 It has been pointed out that the new ~E, ~F, ~G directives
may require negative parameter values in some cases (for the scale
factor), so it becomes desirable to be able to write "~12,4,2,-5E"
instead of having to write "~12,4,2,VE" and supply the scale factor
as an argument -5. Therefore change format to permit decimal
parameter values to be signed (for consistency with other decimal
notations in the language, a redundant "+" is allowed, as well as
"-", as in "~12,4,2,+5E").
--- 299 Clarification of format: It is an error if no argument remains
for a directive requiring an argument, but it is not an error if one or
more arguments remain unprocessed by a directive.
*** 299 Clarification of format output to a string: it is as
if vector-push-extend were used, not vector-push.
--- 300 Add this clarification for format:
It is an error to give a format directive more parameters than it is
described here as accepting. It is an also error to give colon or atsign
modifiers to a directive in a combination not specifically described here
as being meaningful.
--- 302 There is a problem with fixed-format floating-point printout
where no explicit width is specified for the field. Some implementations
support extremely large floating-point exponent values, such as 2↑24 or
more. We really don't want to cause the accidental printing of one
million insignificant digits. Therefore add this note for ~F:
If w is omitted, then if the magnitude of arg is so large (or, if d is
also omitted, so small) that more than 100 digits would have to be
printed, then an implementation is free, at its discretion, to print the
number using exponential notation instead, as if by the directive ``~E''
(with all parameters to ~E defaulted, not taking their values from the ~F
directive).
--- 302 Rewrite the paragraph about when w and d are omitted from ~F as
follows. (The previous version unintentionally implied, by equating the
case to the use of prin1 exactly, that exponential format would be used
outside the range 10↑-3 to 10↑7.)
If both w and d are omitted, then the effect is to print the value using
ordinary free-format output; prin1 uses this format for numbers whose
magnitude is between 10↑-3 (inclusive) and 10↑7 (exclusive).
--- 302 Rewrite the paragraph about when w, d, and e are omitted from ~E
as follows. (The previous version unintentionally implied, by equating
the case to the use of prin1 exactly, that exponential format would not
be used in the range 10↑-3 to 10↑7.)
If all of w, d, and e are omitted, then the effect is to print the value
using ordinary free-format exponential-notation output; prin1 uses this
format for numbers whose magnitude is less than 10↑-3 or greater than or
equal to 10↑7.
--- 303 Add these notes to the descriptions of ~F, ~E, and ~$:
If arg is a rational number, then it is coerced to be a single-float and
then printed. (Alternatively, an implementation is permitted to process
a rational number by any other method that has essentially the same
behavior but avoids such hazards as loss of precision or overflow because
of the coercion. However, note that if w and d are unspecified and the
number has no exact decimal representation, for example 1/3, some
precision cutoff must be chosen by the implementation: only a finite
number of digits may be printed.)
(If it is desired to print each of the real part and imaginary part of a
complex number using a ~F (~E, ~$) directive, then this must be done
explicitly with two ~F (~E, ~$) directives and code to extract the two
parts of the complex number.)
--- 303 The example of the printing of 100.0 in format ~6F was incorrect.
It was |100.00|, and should be | 100.0|.
*** 303 Very embarassing error! I misinterpreted the FORTRAN standard.
When the scale factor k for ~E is negative, the -k zeros should appear
after the decimal point, not before it. The correct full specification is:
If k is negative, then it must be strictly greater than -d; a single zero
digit appears before the decimal point if the total field width will
permit it, and after the decimal point are printed first -k zeros and
then d+k significant digits.
Also, add the following example:
As an example of the effects of varying the scale factor, the code
(dotimes (k 13)
(format t "~%Scale factor ~2D: |~13,6,2,VE|"
(- k 5) 3.14159))
produces the following output:
Scale factor -5: | 0.000003E+06|
Scale factor -4: | 0.000031E+05|
Scale factor -3: | 0.000314E+04|
Scale factor -2: | 0.003142E+03|
Scale factor -1: | 0.031416E+02|
Scale factor 0: | 0.314159E+01|
Scale factor 1: | 3.141590E+00|
Scale factor 2: | 31.41590E-01|
Scale factor 3: | 314.1590E-02|
Scale factor 4: | 3141.590E-03|
Scale factor 5: | 31415.90E-04|
Scale factor 6: | 314159.0E-05|
Scale factor 7: | 3141590.E-06|
*** 304 Change definition of ~E so that if the third parameter ("e") is
omitted then, rather than defaulting to 2, it defaults to the smallest
number which enables the exponent to be printed; that is, the exponent is
printed without extraneous leading zeros. This makes its behavior more
like that of the first two parameters.
--- 304 Add examples of the use of a negative scale factor k in ~E
(third column of sample results shown below). Also demonstrates @ modifier.
Also correct various bugs.
(defun foo (x)
(format nil
"~9,2,1,,'*E|~10,3,2,2,'?,,'$E|~9,3,2,-2,'%@E|~9,2E"
x x x x))
(foo 3.14159) => " 3.14E+0| 31.42$-01|+.003E+03| 3.14E+0"
(foo -3.14159) => " -3.14E+0|-31.42$-01|-.003E+03| -3.14E+0"
(foo 1100.0) => " 1.10E+3| 11.00$+02|+.001E+06| 1.10E+3"
(foo 1100.0L0) => " 1.10L+3| 11.00$+02|+.001L+06| 1.10L+3"
(foo 1.1E13) => "*********| 11.00$+12|+.001E+16| 1.10E+13"
(foo 1.1L120) => "*********|??????????|%%%%%%%%%|1.10L+120"
(foo 1.1L1200) => "*********|??????????|%%%%%%%%%|1.10L+1200"
--- 304 Add examples of the use of a zero scale factor k in ~G
(third column of sample results shown below), and correct bugs
in second column for the ~F case.
(defun foo (x)
(format nil "~9,2,1,,'*G|~9,3,2,3,'?,,'$G|~9,3,2,0,'%G|~9,2G"
x x x))
(foo 0.0314159) => " 3.14E-2|314.2$-04|0.314E-01| 3.14E-2"
(foo 0.314159) => " 0.31 |0.314 |0.314 | 0.31 "
(foo 3.14159) => " 3.1 | 3.14 | 3.14 | 3.1 "
(foo 31.4159) => " 31. | 31.4 | 31.4 | 31. "
(foo 314.159) => " 3.14E+2| 314. | 314. | 3.14E+2"
(foo 3141.59) => " 3.14E+3|314.2$+01|0.314E+04| 3.14E+3"
(foo 3141.59L0) => " 3.14L+3|314.2$+01|0.314L+04| 3.14L+3"
(foo 3.14E12) => "*********|314.2$+10|0.314E+13| 3.14L+12"
(foo 3.14L120) => "*********|?????????|%%%%%%%%%|3.14L+120"
(foo 3.14L1200) => "*********|?????????|%%%%%%%%%|3.14L+1200"
--- 305 Add this note for ~$, similar to the one for ~F:
If the magnitude of arg is so large that more than m digits would have to
be printed, where m is the larger of w and 100, then an implementation is
free, at its discretion, to print the number using exponential notation
instead, as if by the directive ``~w,q,,,,padcharE'', where w and padchar
are present or omitted according to whether they were present or omitted
in the ~$ directive, and where q=d+n-1, where d and n are the (possibly
default) values given to the ~$ directive.
--- 305 In the definition of ~G as equivalent to ~F for some cases,
the occurrence of ~eeT should be ~ee@T. In the definition of ~G
as equivalent to ~E for some cases, it should be "~w,d,e,k,...E",
not "~ww,dd,ee,kk,...E".
*** 306 Delete second definition of ~G (the one that appears after ~*).
This was left in by accident. ~@* now means what ~G used to mean.
*** 306 Change the specification for ~T slightly. It should attempt to
determine the current absolute column position directly from the
destination. If that fails, it should attempt to deduce the column
position from clues such as the most recent ~% or ~& directive, or ~A
whose argument string contained a newline, or whatever, and counting
characters since that point. If that fails, it may try a similar
deduction based on the riskier assumption that the destination was at
column zero when format was first invoked. Failing all that (a
concession to existing implementations that might be hard to rewrite),
output two spaces.
--- 307 Change the specification of ~?. I was wedged when I specified
this originally. You need it in two forms. What was called ~? is now
called ~@?; the reason for this incompatible change is so that the @
modifier or lack thereof will parallel its meaning for ~{. The new
specification is as follows:
For ~?, the next arg must be a string, and the one after it a list; both
are consumed by the ~? directive. The string is processed as a format
control string, with the elements of the list as the arguments. Once the
recursive processing of the control string has been finished, then
processing of the control string containing the ~? directive is resumed.
With the @ modifier, only one arg is directly consumed. The arg must be
a string; it is processed as part of the control string as if it had
appeared in place of the ~@? construct, and any directives in the
recursively processed control string may consume arguments of the control
string containing the ~@? directive.
--- 309 Add this clarification of ~@{ :
If the iteration is terminated before all the remaining arguments are
consumed, then any arguments not processed by the iteration remain to be
processed by any directives following the iteration construct.
*** 312 This was accidentally omitted from the Excelsior edition:
y-or-n-p and yes-or-no-p used to take arguments in the form
"&optional message stream". Now they take no stream argument, but
always use *query-io*, and take arguments as for format:
"&optional format-string @rest arguments".
*** 316 Pathname property lists have been removed from Common LISP.
--- 317 Loosen up the requirements on structured pathname components.
The new spec is as follows: The device, directory, and name also can each
be a string (with host-dependent rules on allowed characters and length)
or possibly some other Common LISP data structure (in which case such a
component is said to be ``structured'', and has an
implementation-dependent format). Structured components may be used to
handle such file system features as hierarchical directories. Common
LISP programs do not need to know about structured components unless they
do host-dependent operations. Specifying a string as a pathname
component for a host that requires a structured component will cause
conversion of the string to the appropriate form.
*** 317 Not all implementations can easily support :oldest as a pathname
version. The paragraph describing the version component has been amended
as follows:
The version is either a positive integer or a special symbol. The
meanings of nil and :wild have been explained above. The keyword :newest
refers to the largest version number that already exists in the file
system when reading a file, or a version number greater than any already
existing in the file system when writing a new file. Some Common LISP
implementors may choose to define other special version symbols. Some
semi-standard names (suggested but not required to be supported by every
Common LISP implementation): :oldest, to refer to the smallest version
number that exists in the file system; :previous, to refer to the version
previous to the newest version; and :installed, to refer to a version
that is officially installed for users (as opposed to a working or
development version. Some Common LISP implementors may also choose to
attach a meaning to non-positive version numbers (a typical convention is
that 0 is synonymous with :newest and -1 with :previous), but such
interpretations are implementation-dependent.
--- 318 Add a note that equal, not eql, is the best way to compare
pathnames for equality.
--- 318 Clarify that truename returns the ``true name'' as a pathname.
--- 318 A clarification for truename: An error is signalled if an
appropriate file cannot be located within the file system for the given
@i[pathname].
*** 319 The function parse-namestring has its convention argument renamed
back to host. The break-characters argument is flushed. The start and
end arguments, and a new argument junk-allowed, are now keyword
arguments. (This makes parse-namestring much more similar to
parse-integer.) Some of the new specs for parse-namestring:
This function does not, in general, do defaulting of pathname components,
even though it has an argument named defaults; it only does parsing. The
host and defaults arguments are present because in some implementations
it may be that a namestring can only be parsed with reference to a
particular file name syntax of several available in the implementation.
If host is non-nil, it must be a host name that could appear in the host
component of a pathname, or nil; if host is nil then the host name is
extracted from the default pathname in defaults and used to determine the
syntax convention. The defaults argument defaults to the value of
*default-pathname-defaults*.
For a string (or symbol) argument, parse-namestring parses a file name
within it in the range delimited by the :start and :end arguments (which
are integer indices into string, defaulting to the beginning and end of
the string).
If :junk-allowed is not nil, then the first value returned is the
pathname parsed, or nil if no syntactically correct integer was seen.
If :junk-allowed is nil (the default), then the entire substring is
scanned. The returned value is the pathname parsed. An error is
signalled if the substring does not consist entirely of the
representation of a pathname, possibly surrounded on either side by
whitespace characters if that is appropriate to the cultural conventions
of the implementation.
In either case, the second value is the index into the string of the
delimiter that terminated the parse, or the index beyond the substring if
the parse terminated at the end of the substring (as will always be the
case if junk-allowed is false).
If thing is not a string or symbol, then start (which defaults to zero in
any case) is always returned as the second value.
Parsing an empty string always succeeds, producing a pathname with all
components (except the host) equal to nil.
Note that if host is specified and not nil, and thing contains a manifest
host name, an error is signalled if the hosts do not match.
*** 319 Clarification of parse-namestring:
If thing contains an explicit host name and no explicit device name,
then it may be appropriate, depending on the implementation environment,
for parse-namestring to supply the standard default device for that
host as the device component of the resulting pathname.
*** 320 The function pathname-plist has been removed from Common LISP.
*** 320 The treatment of the :defaults argument by make-pathname is
now a bit more useful:
Given some components, make-pathname constructs and returns a pathname.
After the components specified explicitly by the :host, :device,
:directory, :name, :type, and :version arguments are filled in, the
merging rules used by merge-pathnames are used to fill in any missing
components from the defaults specified by the :defaults argument. The
default value of the :defaults argument is a pathname whose host
component is the same as the host component of the value of
*default-pathname-defaults*, and whose other components are all nil.
*** 321 There are difficulties with user-homedir-pathname in some
implementations. Add this clarification:
If it is impossible to determine this information, then nil is returned
instead of a pathname; however, user-homedir-pathname never returns nil
if the host argument is not specified.
*** 321 Eliminate init-file-pathname. This was giving some implementors
headaches, there were anomalies and inconsistencies with the way the
LISP Machine handles it, and I just don't have time to figure it out.
*** 322 Logical pathnames are gone from Common LISP. They were based on
an old version of the LISP Machine spec, and nobody seems to want them.
Section 23.1.4 is simply excised from the manual.
*** 322 A slight improvement to the defaulting of the device component of
a pathname: if the given pathname explicitly specifies a host and does
not supply a device, then @new[if the host component of the defaults
matches the host component of the given pathname, then the device is
taken from the defaults; otherwise] the device will be the default file
device for that host.
*** 324 Add this clarification to the documentation of the function open:
The filename argument is the name of the file to be opened; it may be a
string, a pathname, or a stream. (If the filename is a stream, then it
is not closed first or otherwise affected; it is used merely to provide a
file name for the opening of a new stream.)
--- 325 Flush the type standard-char as a permitted value of the
:element-type option to open. There are too many thorny issues, about
what to do if a non-standard character is seen, that were left unbound
and that I fear to define unilaterally.
--- 326 Add this clarification to the :if-exists keyword of open:
If the :direction is :output or :io and the value of :if-exists is
:new-version, then the version of the (newly created) file that is opened
will be one greater than that of any other file in the file system whose
other pathname components are the same as those of the argument filename.
If the :direction is :input or :probe or the value of :if-exists is not
:new-version, and the version component of the argument filename is
:newest, then the file opened is that file already existing in the file
system that has a version greater than that of any other file in the file
system whose other pathname components are the same as those of the
argument filename.
--- 326 Add this implementation note at the end of the descriptions
of the options for the :if-exists keyword for the open function:
Implementation note: The various file systems in existence today have
widely differing capabilities. A given implementation may not be able to
support all of these options in exactly the manner stated. An
implementation is required to recognize all of these option keywords and
to try to do something ``reasonable'' in the context of the host
operating system. Implementors are encouraged to approximate the
semantics specified here as closely as possible.
As an example, suppose that a file system does not support distinct file
versions and does not distinguish the notions of deletion and expunging
(in some file systems file deletion is reversible until an expunge
operation is performed). Then :new-version might be treated the same as
:rename or :supersede, and :rename-and-delete might be treated the same
as :supersede.
If it is utterly impossible for an implementation to handle some option
in a manner close to what is specified here, it may simply signal an
error. The opening of files is an area where complete portability is too
much to hope for; the intent here is simply to make things as portable as
possible by providing specific names for a range of commonly supportable
options.
*** 328 Add these clarifications to the documentation of rename-file:
The file may be a string, a pathname, or a stream. If it is an open
stream associated with a file, then the stream itself and the file
associated with it are affected (if the file system permits).
If the renaming operation is not successful, an error is signalled.
It is an error to specify a filename containing a :wild component, for
the file argument to contain a nil component where the file system does
not permit a nil component, or for the result of defaulting missing
components of the new-name argument from the file argument to contain a
nil component where the file system does not permit a nil component.
*** 328 Formerly rename-file returned t. Change this to be more useful:
rename-file returns three values if successful. The first value is the
new-name with any missing components filled in by performing a
Merge-pathnames operation using file as the defaults. The second value
is the truename of the file before it was renamed. The third value is
the truename of the file after it was renamed.
*** 328 Add these clarifications to the documentation of delete-file:
The file may be a string, a pathname, or a stream. If it is an open
stream associated with a file, then the stream itself and the file
associated with it are affected (if the file system permits), in which
case the stream may or may not be closed immediately, and the deletion
may be immediate or delayed until the stream is explicitly closed,
depending on the requirements of the file system.
If the deletion operation is not successful, an error is signalled.
It is an error to specify a filename containing a :wild component,
or one containing a nil component where the file system does not
permit a nil component.
*** 328 A suggestion that should have made it into Excelsior: change the
name of file-creation-date to file-write-date, because experience has
shown that many people find the former name confusing. Change the
description to: "This returns the time at which the file was created or
last written..."
*** 328 For the function file-position, instead of using nil to mean
the beginning of the file and t to mean the end (or is it t for the
beginning, and nil for the end?), use the keywords :start and :end.
--- 328 Character-set translations can cause problems with the current
specification of file-position. The spec is therefore loosened up
a bit for character files. The new spec is as follows:
(file-position <file-stream>) returns a non-negative integer indicating
the current position within the file-stream, or nil if this cannot be
determined. The file position at the start of a file will be zero. The
value returned by file-position increases monotonically as input or
output operations are performed. For a character file, performing a
single read-char or write-char operation may cause the file position to
be increased by more than 1 because of character-set translations (such
as translating between the Common LISP #\Return character and an external
ASCII carriage-return/line-feed sequence) and other aspects of the
implementation. For a binary file, every read-byte or write-byte
operation increases the file position by 1.
(file-position <file-stream> <position>) sets the position within
file-stream to be position. The position may be an integer, or :start
for the beginning of the stream, or :end for the end of the stream. If
the integer is too large or otherwise inappropriate, an error is
signalled (the file-length function returns the length beyond which
file-position may not access). An integer returned by file-position of
one argument should, in general, be acceptable as a second argument for
use with the same file. With two arguments, file-position returns t if
the repositioning was performed successfully, or nil if it was not (for
example, because the file was not random-access).
Implementation note: Implementations that have character files
represented as a sequence of records of bounded size might choose to
encode the file position as, for example,
<record number>*256+<character within record>.
This is a valid encoding because it increases monotonically as each
character is read or written, though not necessarily by 1 at each step.
An integer might then be considered ``inappropriate'' as a second
argument to file-position if, when decoded into record number and
character number, it turned out that the specified record was too short
for the specified character number.
*** 328 Add this clarification of probe-file:
Note that if the file argument is an open stream associated with a file,
then probe-file cannot return nil, but will produce the true name of the
associated file.
*** 329 In the load function, make the first argument (filename) required
instead of optional. Missing components of the filename are defaulted
from *default-pathname-defaults*. Eliminate the :set-default-pathname
keyword argument.
*** 330 Eliminate *load-pathname-defaults* and *load-set-default-pathname*.
--- 335 The syntax of assert used to be
(assert test-form {place}* [ string {arg}* ] )
and the string was not evaluated. Now it is
(assert test-form [ ({place}*) [ string {arg}* ] ] )
and the string is evaluated.
--- 335 The string argument to check-type was incorrectly specified
as not being evaluated. It is evaluated. However, the typespec
argument is, as specified, not evaluated.
*** 340 In the compile-file function, make the first argument (filename)
required instead of optional. Missing components of the filename are
defaulted from *default-pathname-defaults*. Eliminate the
:set-default-pathname keyword argument.
*** 340 Eliminate *compile-file-set-default-pathname*.
*** 342 Change describe to return no values. You don't want whatever
object you had described to be dumped out all mean and ugly on your
screen and cause the nice description to scroll off into the bit bucket.
--- 344 Add this clarification: Universal Time represents time as a
single non-negative integer.... Because the Common LISP Universal Time
representation uses only non-negative integers, times before the base
time of midnight, January 1, 1900 GMT cannot be processed by Common LISP.
∂05-Dec-83 0843 @MIT-MC:BSG@SCRC-TENEX :IF-EXISTS :SUPERSEDE vs. :NEWEST
Received: from MIT-MC by SU-AI with TCP/SMTP; 5 Dec 83 08:43:32 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Mon 5-Dec-83 11:30:50-EST
Date: Monday, 5 December 1983, 11:25-EST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
To: Common-Lisp at SU-AI
Cc: file-protocol at SCRC-TENEX, cwh at SCRC-TENEX, moon at SCRC-TENEX,
jwalker at SCRC-TENEX
We are having a little dispute here about the intended semantics of
:IF-EXISTS :SUPERSEDE on output, when the file version of the pathname
to be opened is :NEWEST. The manual is not specific on what this means.
It seems as though it says, "Well, if there are any versions, find out
what the latest version is, and make believe you were attempting to
create that version with :IF-EXISTS :SUPERSEDE." I contend that this
combination of arguments with :newest is sheer combinatorial fallout
from the spec, and is not only not useful, but this interpretation is
negatively useful.
First of all, :SUPERSEDE is intended for creating specific versions
and non-versionated file systems. On non-versionated file systems,
it is usually the only file regeneration option you get. If you
say :SUPERSEDE, you want to create a.b.3 no matter what. If you
say :SUPERSEDE with a.b.newest, you want to create a.b.newest, which
is done by creating a new version, no matter what.
Argument #1:
Imagine a program that took user input for a file name, and wrote
out to that file. (Can't argue with that, right?). Suppose further
that this program did not like the CL default of :error, and wanted
you to be able to write out to a.b.3 if that's what you said.
So it might open its file with :IF-EXISTS :SUPERSEDE. Well, suppose
you said a.b.newest to it? You CERTAINLY don't want it looking up
what the latest version is and superseding it! You want it to create
a new version.
Argument #2:
Given the primitives available to the file server in versionated
operating systems, it is impossible to implement this as proposed
without a window between determining the version number and opening
it for superseding.
Carl Hoffman says,
"I have an application which periodically dumps some data to the file a.b.
Each time it makes such a dump, the previous data is no longer interesting to
me, so I dump the data to the same file repeatedly, rather than filling up the
directory with unwanted versions. But, sometimes, I want to save one of the
dumps, so I create a new version of a.b, and the program will begin writing to
that new version instead. If there are no versions of a.b in the directory
at all, then I want a new version to be created, of course.
:IF-DOES-NOT-EXIST :CREATE is assumed."
He should write his data to a.b.1 and copy it when he wants to.
Has CMU implemented this combination? With what interpretation?
Does anyone else have feelings about the rightness or wrongness
of either, or any other, interpretation? How do :OVERWRITE/:TRUNCATE
shed any light on this, if any
∂05-Dec-83 0921 WHOLEY@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE vs. :NEWEST
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Dec 83 09:21:18 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 5 Dec 83 12:20:59-EST
Date: Mon, 5 Dec 1983 12:20 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, cwh%SCRC-TENEX@MIT-ML.ARPA,
file-protocol%SCRC-TENEX@MIT-ML.ARPA, jwalker%SCRC-TENEX@MIT-ML.ARPA,
moon%SCRC-TENEX@MIT-ML.ARPA
Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Has CMU implemented this combination? With what interpretation?
Fortunately for implementors (and unfortunately for users), the Spice file
system does not yet support version numbers other than 1. So we haven't had to
deal with this stuff in any deep way.
∂05-Dec-83 0928 FAHLMAN@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE vs. :NEWEST
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 5 Dec 83 09:26:42 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 5 Dec 83 12:26:34-EST
Date: Mon, 5 Dec 1983 12:26 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Bernard S. Greenberg <BSG%SCRC-TENEX@MIT-ML.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, cwh%SCRC-TENEX@MIT-ML.ARPA,
file-protocol%SCRC-TENEX@MIT-ML.ARPA, jwalker%SCRC-TENEX@MIT-ML.ARPA,
moon%SCRC-TENEX@MIT-ML.ARPA
Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
In-reply-to: Msg of 5 Dec 1983 11:25-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>
Bernie's arguments sound good to me. Generating a newer file instead of
clobbering the old one seems like the least treacherous option. If I
really do want to clobber the newest file, that's easy to do -- just
find it and ask for exactly that version to be superseded. I might even
go farther and outlaw the use of any wild-cardish things in the pathname
given to a supersede. After a couple of years of forced confinement on
a Tops-10 system, I have a very healthy respect for the number of subtle
ways that superseding can screw you.
To answer the specific question, CMU's Spice file-name server currently
does not provide file versions, though that will be changing any week
now. Until we get the new name-server in Spice, we have only made a
rather half-hearted effort to implement all these options in a temporary
way -- we've done only what we need most and have not worried a lot
about the funny combinations. So I'm afraid we provide no precedent.
I've lost track of just what the VMS implementation does on this.
By the way, we probably want to start up some sort of "Rulings on
Ambiguities" file in a generally accessible place. Once the manual is
in print, there will still be issues like this that come up, that we
reach some sort of consensus on, and that we want to chisel into some
sort of stone (probably soapstone, not granite). This should not
contain all the random discussion, but just the questions, answers, and
maybe some rationale. Guy seems the obvious choise to maintain this,
unless he wants to pass the baton to someone else.
-- Scott
∂05-Dec-83 2015 @MIT-ML:Moon%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
Received: from MIT-ML by SU-AI with TCP/SMTP; 5 Dec 83 20:15:13 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 5-Dec-83 22:55:01-EST
Date: Mon, 5 Dec 83 23:12 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: :IF-EXISTS :SUPERSEDE
To: Carl Hoffman <CWH%SCRC-TENEX@MIT-MC.ARPA>,
"Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>,
Skef Wholey <Wholey@CMU-CS-C.ARPA>,
"Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA,
ROM%SCRC-TENEX@MIT-MC.ARPA, file-protocol%SCRC-TENEX@MIT-MC.ARPA,
jwalker%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 4 Dec 83 16:57-EST from Carl Hoffman <CWH at SCRC-TENEX>,
The message of 5 Dec 83 11:25-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>,
The message of 5 Dec 83 11:25-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>,
The message of 5 Dec 83 12:20-EST from Skef Wholey <Wholey at CMU-CS-C>,
The message of 5 Dec 83 12:20-EST from Skef Wholey <Wholey at CMU-CS-C>,
The message of 5 Dec 83 12:26-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 5 Dec 83 12:26-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>,
The message of 5 Dec 83 14:32-EST from Carl Hoffman <CWH at SCRC-TENEX>
Date: Monday, 5 December 1983, 11:25-EST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
We are having a little dispute here about the intended semantics of
:IF-EXISTS :SUPERSEDE on output, when the file version of the pathname
to be opened is :NEWEST. The manual is not specific on what this means.
It (Excelsior edition) says "This differs from :NEW-VERSION in that
:SUPERSEDE creates a new file with the same name as the old one". That
seems quite specific to me. If you write a.b.newest in :IF-EXISTS
:SUPERSEDE mode, you create a new file with the same version number as
the newest existing version of a.b, replacing (superseding) that
existing file.
It might be valuable for the manual to contain a note such as "if the
version component of the pathname is :NEWEST, then one of two rules
for developing a specific version number is used. If the value of
:DIRECTION is :OUTPUT or :IO and the value of :IF-EXISTS is :NEW-VERSION,
then a version number one higher than the highest existing version is
used. In all other cases, the highest existing version is used."
Argument #1:
Imagine a program that took user input for a file name, and wrote
out to that file. (Can't argue with that, right?). Suppose further
that this program did not like the CL default of :error, and wanted
you to be able to write out to a.b.3 if that's what you said.
So it might open its file with :IF-EXISTS :SUPERSEDE. Well, suppose
you said a.b.newest to it? You CERTAINLY don't want it looking up
what the latest version is and superseding it! You want it to create
a new version.
This is a good point; a program with such a user interface needs to check
pathname-version of its pathname to decide what :IF-EXISTS option to use,
since we failed to provide one that implements that behavior.
Argument #2:
Given the primitives available to the file server in versionated
operating systems, it is impossible to implement this as proposed
without a window between determining the version number and opening
it for superseding.
This argument is false. The Tops-20/Tenex Chaosnet file server has
no problem doing this without windows. During the time between opening
and closing, the old file is in an "open for reading" state that
prevents anyone else from superseding it or renaming it. Presumably other
versionated operating systems may have comparable primitives.
It seems to me that what we must do is quite clear and there are no
choices to be made.
∂06-Dec-83 0730 @MIT-MC:BSG%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Dec 83 07:29:56 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Tue 6-Dec-83 10:33:57-EST
Date: Tue, 6 Dec 83 10:30 EST
From: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Subject: :IF-EXISTS :SUPERSEDE
To: Moon%SCRC-TENEX@MIT-MC.ARPA, CWH%SCRC-TENEX@MIT-MC.ARPA,
Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA, Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA,
ROM%SCRC-TENEX@MIT-MC.ARPA, file-protocol%SCRC-TENEX@MIT-MC.ARPA,
jwalker%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 5 Dec 83 23:12-EST from David A. Moon <Moon at SCRC-TENEX>
Date: Monday, 5 December 1983, 23:12-EST
From: David A. Moon <Moon at SCRC-TENEX>
Argument #2:
Given the primitives available to the file server in versionated
operating systems, it is impossible to implement this as proposed
without a window between determining the version number and opening
it for superseding.
This argument is false. The Tops-20/Tenex Chaosnet file server has
no problem doing this without windows. During the time between opening
and closing, the old file is in an "open for reading" state that
prevents anyone else from superseding it or renaming it. Presumably other
versionated operating systems may have comparable primitives.
Could you detail the sequence of operations? The above is not sufficiently
clear. When do you open the second file? Under what name?
∂06-Dec-83 0729 @MIT-MC:BSG%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Dec 83 07:27:50 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN with CHAOS; Tue 6-Dec-83 10:31:56-EST
Date: Tue, 6 Dec 83 10:28 EST
From: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Subject: :IF-EXISTS :SUPERSEDE
To: Moon%SCRC-TENEX@MIT-MC.ARPA, CWH%SCRC-TENEX@MIT-MC.ARPA,
Wholey@CMU-CS-C.ARPA, Fahlman@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA, Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA,
ROM%SCRC-TENEX@MIT-MC.ARPA, file-protocol%SCRC-TENEX@MIT-MC.ARPA,
jwalker%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 5 Dec 83 23:12-EST from David A. Moon <Moon at SCRC-TENEX>
Date: Monday, 5 December 1983, 23:12-EST
From: David A. Moon <Moon at SCRC-TENEX>
It seems to me that what we must do is quite clear and there are no
choices to be made.
I "fixed" the Lisp machine, LMFS and COPYF to act in accordance with the
non-ambiguity you observe (patched). COPYF now works to extant,
numeric-versioned targets again.
The Common Lisp manual should contain the following quote from the new COPYF
(OPEN....
':IF-EXISTS
(IF (EQ (SEND TO-PATHNAME ':VERSION) ':NEWEST)
':NEW-VERSION
':SUPERSEDE)..
under the description of :SUPERSEDE, and state that unless you
include it in your program, if you use :SUPERSEDE, you will
stop having a versionated file system.
Yes, it is consistent, and yes, I still believe there is a language
problem. I call to rememberance the PL/I addition operator......
Perhaps :IF-EXISTS :SUPERSEDE should be the default for a non-:NEWEST
version on output (as it used to be, de facto, around here), removing
the temptation to fall into the above hole.
∂06-Dec-83 1256 @MIT-MC:Moon%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Dec 83 12:56:11 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Tue 6-Dec-83 15:58:21-EST
Date: Tue, 6 Dec 83 15:54 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: :IF-EXISTS :SUPERSEDE
To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: CWH%SCRC-TENEX@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA,
Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI.ARPA,
Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA, ROM%SCRC-TENEX@MIT-MC.ARPA,
file-protocol%SCRC-TENEX@MIT-MC.ARPA, jwalker%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 6 Dec 83 10:30-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>
Date: Tuesday, 6 December 1983, 10:30-EST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Date: Monday, 5 December 1983, 23:12-EST
From: David A. Moon <Moon at SCRC-TENEX>
Argument #2:
Given the primitives available to the file server in versionated
operating systems, it is impossible to implement this as proposed
without a window between determining the version number and opening
it for superseding.
This argument is false. The Tops-20/Tenex Chaosnet file server has
no problem doing this without windows. During the time between opening
and closing, the old file is in an "open for reading" state that
prevents anyone else from superseding it or renaming it. Presumably other
versionated operating systems may have comparable primitives.
Could you detail the sequence of operations? The above is not sufficiently
clear. When do you open the second file? Under what name?
Sure. Here's the sequence of operations, translated from Midas to English:
Do a GTJFN to look up the file name specified. The options specified
are one of the following cases:
- direction is not output => tell the system to look up an existing
version, complain if no file is found, and never create a new file.
- direction is output (no bidirectional support yet);
if append, overwrite, or truncate is set and create is not
=> tell the system to barf if no file is found and to look
up an existing version if newest is specified.
- if any of supersede, append, overwrite, truncate, rename, rename-and-delete,
or if-exists-error is set
=> tell the system to look up an existing version if the version is
newest, rather than creating a new version, and tell it to barf if
an existing file is found.
- otherwise => tell it to create a new file if the version is newest
and to barf if an existing file is found.
The result of this GTJFN is # cases:
(1) A file is found/created with no error => use it
(2) An error other than file-already-exists, or any error if
if-exists-error was specified => return error to user
(3) File-already-exists error
=> GTJFN again, telling the system to look up the existing file.
[An error here is just signalled to the user, and means someone
changed something, e.g. deleted the existing file out from under
you. Probably should start over rather than erring out.]
Now if append, overwrite, or truncate is set, use that file.
Otherwise save that file, along with a flag saying whether
rename, rename-and-delete, or supersede was specified. Open
the file for input with the "restricted" option so that no
one else can mess with it; if this fails return an error;
Tops-20 doesn't allow you to supersede a file that someone
is using, unlike some other systems that will hold onto the
file until all users of it close.
Now open a temporary file in the same directory and use it.
At non-abort close time, rename the temporary file on top of
the other file, superseding it. (For rename/rename-and-delete,
the other file is renamed out of the way first).
Hopefully I haven't perpetrated too many typographical errors in the
above. I don't think the Tops-20 strangeness of having separate system calls
to get a handle on a file and to open a file is depended on in any
fundamental way.
∂06-Dec-83 1435 FAHLMAN@CMU-CS-C.ARPA Exporting Structures
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Dec 83 14:35:13 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 6 Dec 83 17:34:22-EST
Date: Tue, 6 Dec 1983 17:34 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Exporting Structures
We now have some real Common Lisp users around here, and they are
finding the holes at a steady pace. One, found by Mike Jones, concerns
the interaction of packages and DEFSTRUCT. Unless I'm missing
something, the language currently has no way to tell a DEFSTRUCT to
export all of the various accessors and other forms it defines. You
don't want exporting by default -- the majority of structures are for
internal use within a subsystem -- but when you do want to export all of
the handles on some structure it is a pain to do this for each accessor.
Proposal: add an :EXPORT option to DEFSTRUCT that causes each of the
defined forms to be exported from the current package. (If people like
this solution, it could become one of the "semi-official extensions"
until the second edition of the Common Lisp Book of the Dead takes shape.
-- Scott
∂06-Dec-83 1832 FAHLMAN@CMU-CS-C.ARPA :IF-EXISTS :SUPERSEDE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Dec 83 18:32:21 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 6 Dec 83 21:32:15-EST
Date: Tue, 6 Dec 1983 21:32 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: Bug-Lispm%SCRC-TENEX@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA,
CWH%SCRC-TENEX@MIT-MC.ARPA, file-protocol%SCRC-TENEX@MIT-MC.ARPA,
jwalker%SCRC-TENEX@MIT-MC.ARPA, Moon%SCRC-TENEX@MIT-MC.ARPA,
ROM%SCRC-TENEX@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA
Subject: :IF-EXISTS :SUPERSEDE
In-reply-to: Msg of 6 Dec 1983 10:28-EST from "Bernard S. Greenberg" <BSG%SCRC-TENEX at MIT-MC.ARPA>
OK, I went back and looked at the text and I agree that it is
unambiguous, as Moon says. Any ambiguity comes not from the text but
from the expectations of the reader. I think that we probably could
have come up with something a bit safer, but it is workable as it stands
and we should not mess with this until we start thinking about the next
round of improvements.
-- Scott
∂06-Dec-83 1939 @MIT-MC:Moon%SCRC-TENEX@MIT-MC Exporting Structures
Received: from MIT-MC by SU-AI with TCP/SMTP; 6 Dec 83 19:39:42 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Tue 6-Dec-83 22:43:47-EST
Date: Tue, 6 Dec 83 22:40 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Exporting Structures
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 6 Dec 83 17:34-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Tue, 6 Dec 1983 17:34 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
We now have some real Common Lisp users around here, and they are
finding the holes at a steady pace. One, found by Mike Jones, concerns
the interaction of packages and DEFSTRUCT. Unless I'm missing
something, the language currently has no way to tell a DEFSTRUCT to
export all of the various accessors and other forms it defines. You
don't want exporting by default -- the majority of structures are for
internal use within a subsystem -- but when you do want to export all of
the handles on some structure it is a pain to do this for each accessor.
Proposal: add an :EXPORT option to DEFSTRUCT that causes each of the
defined forms to be exported from the current package. (If people like
this solution, it could become one of the "semi-official extensions"
until the second edition of the Common Lisp Book of the Dead takes shape.
There are currently no automatic exportation things at all. The language
design assumes that you will always list the symbols you want to export in
one place, e.g. in a single call to the function EXPORT.
It is probably reasonable to have some auto-export things, although as
we know this can be dangerous if over-used. DEFSTRUCT is only one application.
Making a "semi official extension" (I assume you really mean it would be a yellow
pages package except that it is inextricably intertwined with DEFSTRUCT proper)
seems like a reasonable idea. I hope the documentation will be less vague
than "causes each of the defined forms to be exported from the current package."
I don't even know what a defined form is.
∂06-Dec-83 2002 FAHLMAN@CMU-CS-C.ARPA Exporting Structures
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 6 Dec 83 20:02:04 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 6 Dec 83 23:02:00-EST
Date: Tue, 6 Dec 1983 23:01 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Exporting Structures
In-reply-to: Msg of 6 Dec 1983 22:40-EST from "David A. Moon" <Moon%SCRC-TENEX at MIT-MC.ARPA>
By "semi-official extension" I mean something like the following:
From time to time we will discover shortcomings in the language that can
be fixed in an upward-compatible way. If the fix is just to add more
functions, then a yellow-pages package is the proper vehicle. But if
the fix is to extend existing things by adding new keyword options or
handling cases that were illegal before, and we all agree that the
change is worthy of inclusion in the next edition of the manual, then we
all just happen to make the same extension to our implementations at the
same time and this change is registered in some central place. That way
we (and our users) will not be wandering off in 27 different directions
that will be incompatible with the change that is going to be adopted.
I suppose that it is not legal for packages to claim portability if they
use such changes prior to their official adoption, but at least people
who jump the gun will be heading in the right direction.
All these bureaucratic mechanisms need to be worked out in greater
detail one of these days.
-- Scott
∂07-Dec-83 0928 @MIT-MC:CWH%SCRC-TENEX@MIT-MC :IF-EXISTS :SUPERSEDE vs. :NEWEST
Received: from MIT-MC by SU-AI with TCP/SMTP; 7 Dec 83 09:28:28 PST
Received: from SCRC-YANGTZE by SCRC-RIVERSIDE with CHAOS; Mon 5-Dec-83 14:29:41-EST
Date: Mon, 5 Dec 83 14:32 EST
From: Carl Hoffman <CWH%SCRC-TENEX@MIT-MC.ARPA>
Subject: :IF-EXISTS :SUPERSEDE vs. :NEWEST
To: BSG%SCRC-TENEX@MIT-MC.ARPA, Wholey@CMU-CS-C.ARPA,
Fahlman@CMU-CS-C.ARPA, Common-Lisp@SU-AI.ARPA
Cc: file-protocol%SCRC-TENEX@MIT-MC.ARPA, moon%SCRC-TENEX@MIT-MC.ARPA,
jwalker%SCRC-TENEX@MIT-MC.ARPA
In-reply-to: The message of 5 Dec 83 11:25-EST from Bernard S. Greenberg <BSG at SCRC-TENEX>,
The message of 5 Dec 83 12:20-EST from Skef Wholey <Wholey at CMU-CS-C>,
The message of 5 Dec 83 12:26-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
As I understand :IF-EXISTS :SUPERSEDE and :TRUNCATE, these two options should
be identical except with respect to the amount of available storage in the
file system while the file is open, and to what action is taken if writing to
the file is aborted. But, most importantly, they should be identical with
respect to whether or not a new file is created. The only reason I would use
:TRUNCATE instead of :SUPERSEDE is if the amount of data being written was a
sizable fraction of the amount of available space in the filesystem.
Currently, in LMFS, (OPEN "a.b.newest" ... :IF-EXISTS :SUPERSEDE) will always
create a new file, but (OPEN "a.b.newest" ... :IF-EXISTS :TRUNCATE) will only
create a new file if no versions of a.b already exist. Regardless of what is
decided for :SUPERSEDE, I would like to see :TRUNCATE work the same way. The
current LMFS behavior is asymmetric and difficult to document.
I feel that either of the proposed behaviors for :SUPERSEDE of a newest
version are reasonable. I can see arguments for either one. Therefore, which
definition is chosen should depend upon how easy it is to get the other
behavior from the chosen one, and what the implications are for the
implementor. I can't comment on the latter issue, but here is an example of
the former.
Given the current LMFS definition for :SUPERSEDE, if I want to supersede the
newest version, I must (in Symbolics Release 5.0) do:
(DEFUN OPEN-SUPERSEDE (PATH)
(IF (NOT (EQ (SEND PATH :VERSION) :NEWEST))
(OPEN PATH :DIRECTION :OUTPUT :IF-EXISTS :SUPERSEDE)
(LET ((FILES (CDR (FS:DIRECTORY-LIST (SEND PATH :NEW-VERSION :WILD)
:SORTED :FAST))))
(IF (NULL FILES)
(OPEN PATH :DIRECTION :OUTPUT)
(OPEN (CAAR (LAST FILES))
:DIRECTION :OUTPUT
:IF-EXISTS :SUPERSEDE)))))
I believe this is what Scott Fahlman suggested I do.
Given the current LMFS definition for :TRUNCATE, if I do not want to truncate
the newest version, I must do:
(DEFUN OPEN-TRUNCATE (PATH)
(OPEN PATH
:DIRECTION :OUTPUT
:IF-EXISTS (IF (EQ (SEND PATH :VERSION) :NEWEST) :TRUNCATE :CREATE)))
In other words, if you know that the version of PATH is :NEWEST, then it is a
simple matter to say :IF-EXISTS :CREATE instead of :IF-EXISTS :SUPERSEDE. But
if you really do want to supersede the newest version, then you must first
list the directory.
The issue I feel strongly about is that :SUPERSEDE and :TRUNCATE should behave
similarly with respect to file creation. I think I convinced Bernie that this
isn't hard to do in LMFS.
Date: Monday, 5 December 1983, 11:25-EST
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
Argument #1:
Imagine a program that took user input for a file name, and wrote
out to that file. (Can't argue with that, right?). Suppose further
that this program did not like the CL default of :error, and wanted
you to be able to write out to a.b.3 if that's what you said.
So it might open its file with :IF-EXISTS :SUPERSEDE. Well, suppose
you said a.b.newest to it? You CERTAINLY don't want it looking up
what the latest version is and superseding it! You want it to create
a new version.
If that is how you wish to define your user-interface, then you should say
:IF-EXISTS :CREATE if the user has specified a pathname with .newest. One
can imagine a user interface which would supersede the newest version.
Argument #2:
Given the primitives available to the file server in versionated
operating systems, it is impossible to implement this as proposed
without a window between determining the version number and opening
it for superseding.
Given what it is that the programmer is trying to do, the window will always
exist. You are just moving the window into user code, as in the
OPEN-SUPERSEDE function defined above.
∂08-Dec-83 2206 pierson%digital%Digital@CSNet-Relay Copy-Seq
Received: from CSNET-CIC by SU-AI with TCP/SMTP; 8 Dec 83 22:03:31 PST
Date: Thu, 8 Dec 83 15:52 EST
From: Dan Pierson <pierson%digital@CSNet-Relay>
Return-Path: <pierson%digital%Digital@CSNet-Relay>
Subject: Copy-Seq
To: common-lisp@SU-AI
Via: Digital; 8 Dec 83 23:50-EST
What should Copy-Seq of a vector with fill-pointer return? The following
are some options:
Return a vector with fill-pointer and copy the elements up to the
fill pointer.
Return a vector with fill-pointer and copy all the elements.
Return a vector without fill pointer with the length set by the
fill pointer.
dan
∂08-Dec-83 2221 WHOLEY@CMU-CS-C.ARPA Copy-Seq
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 8 Dec 83 22:21:49 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Fri 9 Dec 83 01:21:53-EST
Date: Fri, 9 Dec 1983 01:21 EST
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Dan Pierson <pierson%digital@CSNET-CIC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Copy-Seq
In-reply-to: Msg of 8 Dec 1983 15:52-EST from Dan Pierson <pierson%digital at CSNet-Relay>
The Common Lisp Manual says (at the beginning of the sequence functions
chapter) that
Whenever a sequence function must construct and return a new
vector, it always returns a @i[simple] vector. Similarly,
any strings constructed will be simple strings.
∂09-Dec-83 1112 Mailer@MIT-XX Copy-Seq
Received: from MIT-XX by SU-AI with TCP/SMTP; 9 Dec 83 11:12:22 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Fri 9-Dec-83 14:17:00-EST
Date: Fri, 9 Dec 83 14:12 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Copy-Seq
To: Dan Pierson <pierson%digital@CSNET-CIC.ARPA>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 8 Dec 83 15:52-EST from Dan Pierson <pierson%digital at CSNET-CIC>
Date: Thu, 8 Dec 83 15:52 EST
From: Dan Pierson <pierson%digital@CSNet-Relay>
What should Copy-Seq of a vector with fill-pointer return? The following
are some options:
Return a vector with fill-pointer and copy the elements up to the
fill pointer.
Return a vector with fill-pointer and copy all the elements.
Return a vector without fill pointer with the length set by the
fill pointer.
Your third possibility is the way I read the documentation (Excelsior edition),
since COPY-SEQ is equivalent to SUBSEQ and copies sequences, not general objects
with all their arbitrary attributes.
We will leave aside the fact that under COPY-SEQ it says EQUAL where it means EQUALP
and that the manual is silent on interaction between EQUAL/EQUALP and FILL-POINTER;
page 63 implies that EQUAL ignores the FILL-POINTER, which is probably wrong,
while page 234 implies that EQUAL respects the FILL-POINTER.
∂09-Dec-83 2120 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Comments on changes in Mary Poppins edition
Received: from MIT-ML by SU-AI with TCP/SMTP; 9 Dec 83 21:20:11 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Sat 10-Dec-83 00:19:41-EST
Date: Sat, 10 Dec 83 00:18 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Comments on changes in Mary Poppins edition
To: Common-Lisp@SU-AI.ARPA
If we agree that the following are mistakes in the manual they should
go into an errata file to be distributed to readers of the book.
p.245: I don't like the specification that VECTOR-PUSH-EXTEND returns
NIL if given a non-adjustable array whose fill-pointer is equal to its
length. I think it would be more tasteful to say that this signals an
error, or at least that it is an error.
I don't think user programs should have to check the value returned by
VECTOR-PUSH-EXTEND to make sure that it worked.
p.270: It says that if a form typed at top-level returns no values,
* is set to NIL and the *,**,*** and /,//,/// histories are updated.
The last mail I have about this says that the history variables would
be unchanged in this case:
Date: 2 Sep 83 0047 EDT (Friday)
From: Guy.Steele@CMU-CS-A
[Comments by GLS are in square brackets.]
p. 257 (second and fourth paragraphs, and parentheses in the first paragraph):
We agreed to change the rules for * to be consistent with what was printed,
rather than aligned with +, but the manual wasn't updated.
[I remember what was agreed to. + is as before. *, **, *** are updated
every time a result is printed, whether it is the only result or one of
-> several. If an evaluation produces zero values, then * does not change.
/, //, /// are updated when the results of an evaluation are printed,
however many (possibly zero) there are; if the computation is aborted,
/ is not updated.]
Maybe we later agreed to change the no-values case and I just forgot
and didn't save that mail.
p.289: A consequence of the description of how #+ and #- interact with
*read-suppress* is that "#+foo #+bar 1 #-bar 2" is not consistently
skipped if "foo" is false; it reads as the number "2" if "foo" and "bar"
are both false. I think it should always read as nothing.
I think the last bulleted paragraph on page 289 should simply be
deleted; #+ and #- while in *read-suppress* mode behave normally, except
of course they do not turn -off- *read-suppress* mode.
p.310: The example of the ' macro character should be supplying
T as the second argument to READ (eof-error-p).
p.335: There's part of some other document on this page.
p.341: The host argument to parse-namestring would almost never be used
(normally the host would come from the defaults), so it would have been
better to make this argument a keyword argument rather than an optional
argument. Probably it would have been more consistent to make both
optional arguments into keyword arguments. Is it too late?
p.343: The bottom paragraph didn't get updated for the loosening up of
structured pathname components.
p.344: In the explanation of the meaning of ENOUGH-NAMESTRING, I believe
that <defaults> should be supplied in the call to PARSE-NAMESTRING.
Otherwise PARSE-NAMESTRING might parse the string relative to the host of
*DEFAULT-PATHNAME-DEFAULTS*, which could be the wrong host; this means
that ENOUGH-NAMESTRING would be required always to include a host in its
output, which is probably not what you intended.
∂13-Dec-83 2258 Guy.Steele@CMU-CS-A Reply to RMS questions about potential numbers
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 13 Dec 83 22:58:09 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 14 Dec 83 01:43:27 EST
Date: 14 Dec 83 0036 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: rms%oz@MIT-MC
Subject: Reply to RMS questions about potential numbers
CC: common-lisp@SU-AI
Date: Tuesday, 13 December 1983, 15:28-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
If one allows complex numbers to be input as x+yi,
as the Lisp machine does, then in base 16
one clearly must allow 1.6+badi to be a valid input.
But it is not a potential number according to Common Lisp
because the dot in the 1.6 implies that the "bad" cannot be
taken as digits.
This analysis is quite correct.
I think it ruins part of the intended usefulness of the potential number
idea with radices above ten.
I agonized over this before proposing this definition of potential numbers.
The problem is that with large bases like 36 almost any symbol might look
like a number, whether it has punctuation in it or not. The definition
of potential numbers is designed to be flexible for bases below ten,
and to carefully limit the possibilities for confusion for bases above ten.
The attitude in Common LISP is that non-decimal radices are not normally
used for reading in code, but only for specialized data files; one really
is unlikely to want hexadecimal complex numbers.
Also, if someone defines 777777q to be some kind of number, it would
be a real screw if he did not allow 5+777777qi to be valid too.
But that is not a potential number. This is the same sort of problem,
but with base ten.
This analysis is correct. If it is desired to allow non-decimal
non-floating-point complex numbers, I would suggest inserting an
underscore before the "i": 5+777777q←i. Indeed, we might well eventually,
after experimentation, settle on a convention that underscores may
be freely used within numbers and have no significance except as
a separator, so that one might write 3.141←592←653←589←793←238←4
for pi, for example.
I think this is a pretty bad problem with the whole idea: one can make
extension A or extension B, which don't seem to have much to do with each
other, but one cannot make both extensions in the same Lisp system.
Date: Tuesday, 13 December 1983, 15:13-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
I cannot figure out whether BASE is a potential number in radix 16.
Can the S be regarded as a number marker, given that the letters it is
next to are "digits"? In general, it is hard to figure out the precise
definition of potential numbers.
Perhaps additional clarification is in order. However, I point to the
statement "no letter that is adjacent to another letter may ever be
treated as a number marker". So the "S" in "BASE" cannot be treated as
a number marker, no matter what the radix. This definition was quite
intentional, again to limit confusion. The syntax for potential numbers
is specifically not designed to accommodate non-decimal floating-point
numbers. (The suggestion about underscores above would allow one
to write BA←S←E if you really wanted the floating-point number
(* (coerce #xBA 'short-float) (expt 16 #xE))
to result; interpolating the underscores would allow the "S" to be
interpreted as anumber marker.)
Also, that definition is extremely hard to program in BNF, which is
what I am having to do.
I agree that it is hard. I attempted to write such a BNF. Most of
the problem seems to stem from the conditional interpretation of letters
depending on the current input radix (*read-base*). Most of the
difficulties would vanish if it were decreed that every floating-point
number *must* have a decimal point within it (ruling out 1E10, for example).
However, it is not *required* that you distinguish all potential numbers
from other tokens; it is desirable to do so from the point of view of
error checking, but an implementation is permitted to treat as a symbol
any potential number not actually defined by Common LISP to be an actual
number. The main point is to warn the user away from a certain class
of tokens whose interpretation may be subject to change in the future,
and conversely to guarantee that tokens in another certain class will
*not* have their interpretation changed in the future.
∂14-Dec-83 1522 GREEK@DEC-MARLBORO.ARPA Potential numbers
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 14 Dec 83 15:22:11 PST
Date: Wed 14 Dec 83 18:19:36-EST
From: GREEK@DEC-MARLBORO.ARPA
Subject: Potential numbers
To: common-lisp@SU-AI.ARPA
I just read the nth message in what I figure will be an infinite
series of message about the new potential number syntax. These
messages are beginning to sound like the design notes for Ada.
Why don't we do ourselves a favor and get rid of *READ-BASE*?
- Paul Anagnostopoulos
-------
∂14-Dec-83 1604 FAHLMAN@CMU-CS-C.ARPA Potential numbers
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 14 Dec 83 16:02:54 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 14 Dec 83 19:02:34-EST
Date: Wed, 14 Dec 1983 19:02 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: GREEK@DEC-MARLBORO.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Potential numbers
In-reply-to: Msg of Wed 14 Dec 83 18:19:36-EST from GREEK at DEC-MARLBORO.ARPA
Paul,
You weren't around for some of the earlier rounds of this discussion.
*read-base* was flushed, but this caused a fair amount of grief for the
people who had to import lots of code from Lisp Machine Lisp and
Maclisp, both of which are thumbless languages. There was also a
feeling that someone might someday have to load a data file with lots of
octal or hexadecimal numbers in it. For these two reasons, *read-base*
was allowed to sneak back in, though the use of non-decimal *read-base*
in code files is officially frowned upon.
I'm doing myself an even bigger favor: Spice Lisp is blissfully ignoring
the entire "potential number" business, and is simply treating as a
symbol anything not recognizably a number under the current rules. I
view the "potential number" business merely as a warning to programmers
that certain ugly symbol-names might be defined out from under them
someday in some system.
Yes, it would be mroe tasteful for the compiler to issue a warning. No,
I'm not going to add this, ever, unless someone hands me code that
happens to work.
-- Scott
∂14-Dec-83 2150 Guy.Steele@CMU-CS-A Get rid of *READ-BASE* ?
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 14 Dec 83 21:49:53 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Dec 83 00:32:40 EST
Date: 15 Dec 83 0045 EST (Thursday)
From: Guy.Steele@CMU-CS-A
To: GREEK@DEC-MARLBORO
Subject: Get rid of *READ-BASE* ?
CC: common-lisp@SU-AI
In-Reply-To: "GREEK@DEC-MARLBORO.ARPA's message of 14 Dec 83 18:19-EST"
Well, early in the Common LISP game we *did* get rid of *READ-BASE*
(at that time called IBASE), for essentially the same reasons:
it messes up the number syntax something awful. However, in a few
odd situations it is EXTREMELY useful. It's hard to document,
but it is not hard to implement.
--Guy
∂16-Dec-83 2014 Guy.Steele@CMU-CS-A Special declarations
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 16 Dec 83 20:14:23 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 16 Dec 83 23:01:48 EST
Date: 16 Dec 83 2314 EST (Friday)
From: Guy.Steele@CMU-CS-A
To: Richard M. Stallman <RMS%MIT-OZ@MIT-MC>
Subject: Special declarations
CC: common-lisp@SU-AI
In-Reply-To: "Richard M. Stallman's message of 15 Dec 83 17:05-EST"
Thank you for pursuing this bug. There are at least two gross internal
contradictions in the manual with respect to declarations, as a result
of editing errors on my part. I am very sorry for the confusion.
Let me clarify matters.
In your example
(DEFUN FOO (A)
(LET ((A A))
(DECLARE (SPECIAL A))
...)
the reference to A within the initialization of the LET is indeed subject
to the SPECIAL declaration and therefore does not refer to the parameter
named A. This sentence in the first paragraph on page 127 of the Mary Poppins
edition:
However, the reference to x in the first call to foo is
a local reference, not a special one.
is in error and must be rewritten; that reference to x is in fact special.
Martin Griss has also pointed out that the parenthetical remark
(but not the init forms)
that appears in paragraph 2, page 102, of the Mary Poppins edition
(and paragraph 3, page 95, of the Excelsior edition), in the description
of do and do*, is also in error; it should be replaced by a non-parenthetical
to the init forms,
That is, the init forms in do and do* are in fact subject to
declarations in the body in exactly the same way as init forms are in
let and let*.
--Guy
∂18-Dec-83 2236 @MIT-ML:Moon%SCRC-TENEX@MIT-ML Comments on Mary Poppins Chapter 9
Received: from MIT-ML by SU-AI with TCP/SMTP; 18 Dec 83 22:35:49 PST
Date: Monday, 19 December 1983 01:36-EST
from: Moon%SCRC-TENEX@MIT-ML
To: Common-Lisp at su-ai
Subject:Comments on Mary Poppins Chapter 9
The first paragraph on page 127 is bogus in several respects.
- the second sentence is false: the INLINE declaration applies
to both uses of FOO. This is left over from the old complicated
rules for declarations in LET, which were flushed (see p.126).
- the fourth sentence is false: since SPECIAL as applied to -references-
is pervasive, it applies to the initialization forms of the LET.
Again, this is left over from the old complicated rules.
- the declaration of K is irrelevant and confusing.
- the last sentence has "constructs" for "construct".
No way is provided to protect a variable reference from a pervasive SPECIAL
declaration, exposing a local binding -outside- of the SPECIAL declaration.
No way is provided to protect a variable binding from a pervasive SPECIAL
proclamation, making the binding local.
An UNSPECIAL declaration would solve the above two. If the omission of
this was deliberate (was it?), the manual ought to contain a note
explaining the reasoning.
When does COMPILE-FILE recognize PROCLAIM as a top-level form in the file?
(1) Never: put (EVAL-WHEN (COMPILE LOAD EVAL) ...) around it.
(2) Always: make sure non-constant arguments are evaluable at compile time.
(3) Only when the argument is quoted.
(4) Only when the compiler, by analysis, can prove the argument is constant.
Even if the answer is 1, the manual should say so explicitly, since people
reasoning by analogy from Maclisp will expect something else. I can think
of good arguments in support of each of the above four possible answers.
I guess I ought to argue in favor of 1 since it's the simplest; but it
will also lead users to commit the most careless errors.
Is (LET (X) (DECLARE (INTEGER X)) (SETQ X (+ Y Z)) ...) an error? Page 91
says that X is initialized to NIL, which would violate the type
declaration, but also says that it is bad style to depend on this initial
value, and in fact this example does not depend on the initial value. The
manual should be explicit about this since I'm not sure whether the
language intends this to be an error. Probably this belongs with the
description of LET, not the description of DECLARE. Note: in Maclisp, this
gets a warning, but if you (violating good style) look at the value it is
zero in spite of the warning saying it would be NIL.
In the example of the OPTIMIZE declaration on page 130, would it have
been equivalent to put (DECLARE (OPTIMIZE SPEED)) at the front of the
body of the DO, rather than using LOCALLY? I think p.126 implies this.
p.131: "(the string (concatenate x y))" is probably not calling
concatenate with legal arguments. Its first argument is a type specifier
(which of course means that it is useless to wrap a THE around it).
The manual is indeed in fairly good shape for a first release when the only
things I can find to complain about are as non-weighty as these.
∂20-Dec-83 1252 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Declarations
Received: from MIT-ML by SU-AI with TCP/SMTP; 20 Dec 83 12:52:05 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 20-Dec-83 15:53:04-EST
Date: Tue, 20 Dec 83 15:50 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Declarations
To: Common-Lisp@SU-AI.ARPA
I have an alternate proposal for declarations. It is mainly intended as
an easier-to-understand way of explaining things that gives the same
semantics, but it also resolves the inconsistencies in the manual (Mary
Poppins and Excelsior editions) in a way that is probably inconsistent with
the intent of the manual, but is more consistent with the Laser edition and
with the practice in previous lisps such as Maclisp and Lisp Machine Lisp.
I realize it is rather late for this kind of thing, but given that the
manual is inconsistent with itself and that some people were surprised by
the change from last year's version of the language, maybe we can reconsider.
In any case this way of explaining things seems to be easier to understand.
The basic problem is the SPECIAL declaration, which falls into both categories
of declarations: it both concerns the binding of variables and is pervasive.
This is not well explained in the manual and seems to be a great source of
confusion. I propose to flush the idea that SPECIAL declarations are
pervasive. Read on before judging.
There are two disjoint classes of declaration: those that are attached
to a particular variable binding, and those that are not. Note that I
am not discussing proclamations here; they have their own scoping rules
which are different from the rules for declarations.
The scoping rule for the first kind of declaration is that it applies to
precisely the text that is in the lexical scope of the variable binding
with which it is associated. Such declarations are shadowed by a
variable binding for the same name inside their scope. Since the lexical
scoping rules are very well and precisely defined, we already understand
everything about this kind of declaration.
The scoping rule for the second kind of declaration is that it is
pervasive. The declaration is attached to a lambda-expression or to a
form (one of the special forms listed on page 125). The declaration
applies to all text inside that expression or form; there are no special
cases such as init-forms of LET or DO. Such declarations are shadowed
by a conflicting declaration inside their scope.
Possible names for the two kinds of declaration are "lexical" and "pervasive"
or "variable" and "non-variable."
None of this is new. What about SPECIAL declarations? I propose that SPECIAL
declarations be put entirely into the first category, in the following way:
When a declaration, (SPECIAL X), is attached to a form (or lambda-expression)
it creates a -lexical- binding of the name X in that form. Unlike all other
bindings, this binding does not associate a value with the name X. Instead,
it associates a "special" marker with the name. Any text that is in the
lexical scope of this binding, and uses the variable X, refers to the dynamic
binding of X, because it sees the "special" marker. The scope of a SPECIAL
declaration is precisely defined by the scope of this binding. Note how close
this definition is to the way that some interpreters actually work internally.
In addition to creating this lexical binding, a (SPECIAL X) declaration also
changes the meaning of a binding, if there is one, of the variable X in the
form to which the declaration is attached; it causes that binding to be a
dynamic binding rather than a lexical binding. This applies only to the form
to which the declaration is directly attached, not to any subforms of it.
(This is not new.)
The declaration-allowing forms FLET, LABELS, LOCALLY, and MACROLET do
not normally create bindings of variable names (only function names), so
we have a slight exception, permitting SPECIAL declarations inside them
to create such bindings.
We now understand completely how the SPECIAL declaration works in LET.
Three examples:
(defun foo (x)
(let ((x x))
(declare (special x))
(bar x)))
Reading from left to right, there are five occurrences of x. The
declaration causes the second and fifth to refer to a dynamic variable,
while the first and third refer to a lexical variable. (The fourth
occurrence is the one in the declaration itself). The third occurrence
of x does not refer to the dynamic variable, because it is not in the
scope of the lexical binding of the name x created by the special
declaration, because of the way LET defines scoping in its subforms.
(defun foo ()
(declare (special x))
(bar x))
The declaration causes the second occurrence of x to refer, freely, to
a dynamic variable, because this x is inside the lexical scope of a binding
of the name x attached to the defun.
(defun foo ()
(let ((x (quux)))
(mumble x)
(locally
(declare (special x))
(bar x))))
Here the first and second occurrences of x refer to a lexical variable,
while the fourth refers to a dynamic variable. The binding of the name
x in the LOCALLY shadows the binding of the name x in the LET.
There remains the issue of how sequential binding forms such as LET* and DEFUN
should work. (DEFUN uses sequential binding with respect to initial value
forms for &optional, &key, and &aux variables). When a SPECIAL declaration
creates a lexical binding of a name in such a form, at what position in the
sequence of bindings should it be inserted? This makes a difference because
it affects whether the scope of the declaration includes or excludes the
initial value forms. Clearly if the form includes a (dynamic) binding of the
name being declared, then the (lexical) binding created by the declaration
should be inserted at that point. Otherwise we can either insert the
declaration's binding at the beginning of the sequence of bindings, giving it
the largest possible scope, or at the end, giving it the smallest possible
scope. I suggest putting it at the beginning, because that is what people
seem to expect with DEFUN (see the example at the bottom of page 126.)
Two examples:
(defun foo (x)
(let* ((x (bar x))
(y (quu x)))
(declare (special x))
...))
The first and third occurrences of x refer to a lexical variable, while
the second and fourth refer to a dynamic variable. (bar x) is outside
the scope of the special declaration while (quu x) is inside its scope.
(defun foo (x)
(let* ((w (bar x))
(y (quu x)))
(declare (special x))
...))
The first occurrence of x refers to a lexical variable, while the second and
third refer, freely, to a dynamic variable. Both (bar x) and (quu x) are
inside the scope of the special declaration. If let had been used instead of
let*, neither of them would be inside the scope of the declaration.
For explanatory purposes, the above two examples could be written on
paper as
(defun foo (x)
(let* ((x (bar x))
(x @I[special])
(y (quu x)))
(declare (special x))
...))
(defun foo (x)
(let* ((x @I[special])
(w (bar x))
(y (quu x)))
(declare (special x))
...))
∂20-Dec-83 1826 FAHLMAN@CMU-CS-C.ARPA Declarations
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 20 Dec 83 18:26:23 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Dec 83 21:26:09-EST
Date: Tue, 20 Dec 1983 21:26 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Declarations
In-reply-to: Msg of 20 Dec 1983 15:50-EST from "David A. Moon" <Moon%SCRC-TENEX at MIT-MC.ARPA>
Dave,
I like your proposal for special declarations and would gladly have
supported it if you had proposed it last June. I have never felt too
strongly one way or the other about the effect of SPECIAL declarations
on init forms, and your scheme has the merit of clarity. However, I
feel that it is much too late now for any changes in the fundamental
binding mechanisms of the language. Despite some minor inconsistencies
in the manual, it seemed very clear to me from the description in
Excelsior that SPECIAL declarations were supposed to include the init
forms, and that is what we implemented. The finishing touches are now
being added to our system here and to the version at DEC, and I am
totally unwilling to go back and change the compiler and interpreter in
fundamental ways at this time. Even a name change at this point would
be a major hassle.
-- Scott
∂20-Dec-83 1849 FAHLMAN@CMU-CS-C.ARPA Comments on Mary Poppins Chapter 9
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 20 Dec 83 18:48:56 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 20 Dec 83 21:48:51-EST
Date: Tue, 20 Dec 1983 21:48 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Moon%SCRC-TENEX@MIT-ML.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Comments on Mary Poppins Chapter 9
In-reply-to: Msg of 19 Dec 1983 01:36-EST from Moon%SCRC-TENEX at MIT-ML
From MOON:
When does COMPILE-FILE recognize PROCLAIM as a top-level form in the file?
(1) Never: put (EVAL-WHEN (COMPILE LOAD EVAL) ...) around it.
(2) Always: make sure non-constant arguments are evaluable at compile time.
(3) Only when the argument is quoted.
(4) Only when the compiler, by analysis, can prove the argument is constant.
Even if the answer is 1, the manual should say so explicitly, since people
reasoning by analogy from Maclisp will expect something else. I can think
of good arguments in support of each of the above four possible answers.
I guess I ought to argue in favor of 1 since it's the simplest; but it
will also lead users to commit the most careless errors.
I would favor choice 2 and could live with 3 or 4. I am strongly
opposed to choice 1. In practice the argument will always be quoted and
always wants to be noticed at all three times. It is horrible to
contemplate having to put EVAL-WHEN's around all PROCLAIM forms in order
to get this effect.
-- Scott
∂21-Dec-83 1847 Guy.Steele@CMU-CS-A Forwarded mail
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 21 Dec 83 18:47:03 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Dec 83 21:30:11 EST
Date: 21 Dec 83 2144 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Forwarded mail
- - - - Begin forwarded message - - - -
Received: from CMU-CS-PT by CMU-CS-A; 19 Dec 83 22:12:40 EST
Received: from MIT-MC by CMU-CS-PT; 19 Dec 83 21:58:53 EST
Date: 19 December 1983 22:11 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: must be wrong
To: GLS @ MIT-MC
(DEFUN FOO (A)
(LET ((A A))
(DECLARE (SPECIAL A))
...)
the reference to A within the initialization of the LET is indeed subject
to the SPECIAL declaration and therefore does not refer to the parameter
named A.
This sounds like nonsense to me. If the theory of Common Lisp special
declarations really works out this way, then it is broken. There is no
reason for declarations found in the body of LET or DO to effect any aspect
of the initial-value forms.
- - - - End forwarded message - - - -
∂21-Dec-83 1846 Guy.Steele@CMU-CS-A Interchange of interest
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 21 Dec 83 18:46:28 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Dec 83 21:29:01 EST
Date: 21 Dec 83 2143 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Interchange of interest
- - - - Begin forwarded messages - - - -
Received: from CMU-CS-PT by CMU-CS-A; 19 Dec 83 21:15:42 EST
Received: from MIT-MC by CMU-CS-PT; 19 Dec 83 21:01:42 EST
Date: 19 December 1983 21:14 EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: Special declarations
To: Guy.Steele @ CMU-CS-A
If
(DEFUN FOO (A)
(LET ((A A))
(DECLARE (SPECIAL A))
...)
is rewritten as
(defun foo (a)
((lambda (a)
(declare (special a))
...)
a))
is it equivalent? If it is, then there is the interesting consequence
that it is not equivalent to
(defun foo (a)
(funcall #'(lambda (a) (declare (special a)) ...) a))
If it is not, as i presume is the case, perhaps more effort should
have been put in to emphasize the non-equivalence of LET with
its "obvious" macro expansion, which is something which people (and
compilers!) that think they know LET will blow.
I can understand the reasoning that leads up to all of this, i guess
my problem is that it leaves me feeling uncomfortable. About four
years ago i started writing the front-end part for a lisp compiler,
and one thing i couldn't decide how to handle was declaration scoping
with sequential binding (let*, &optional).
- - - - - - - - -
Date: 21 Dec 83 2142 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Glenn S. Burke <GSB@MIT-MC>
Subject: Re: Special declarations
In-Reply-To: "Glenn S. Burke's message of 19 Dec 83 21:14-EST"
I feel that the current declaration semantics are a bit awkward, too,
but I think it's the best we can do. You are quite correct that
(LET ((A A)) (DECLARE (SPECIAL A)) ...)
and
((LAMBDA (A) (DECLARE (SPECIAL A)) ...) A)
are not equivalent, because the A in the initialization form is
special in the first case, but the A that is the argument (not the
formal parameter) to the lambda expression is not special in the
second case.
Indeed, the interpretation of a LET containing declarations is not
trivial, and that is the main reason why it is documented as a
special form, not as a macro, in Common LISP.
--Guy
- - - - End forwarded messages - - - -
∂21-Dec-83 1858 Guy.Steele@CMU-CS-A Re: must be wrong
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 21 Dec 83 18:58:33 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 21 Dec 83 21:39:35 EST
Date: 21 Dec 83 2153 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: Alan Bawden <ALAN@MIT-MC>
Subject: Re: must be wrong
CC: common-lisp@SU-AI
In-Reply-To: "Alan Bawden's message of 19 Dec 83 22:11-EST"
To recapitulate: the reason declarations affect initializer formsis that
we discovered anomalies in the handling of declarations in
such sequential-binding forms as LET* and DO*. For example:
(LET* ((A B)
(B A))
(DECLARE (SPECIAL A B))
...)
Clearly both bindings should be special. Should either initializer
be special? Knotty problems lurk here, and it was somehow decided
that all initializers should be affected in all cases. It is a simple
rule, at least, even though the old explanations of LET in terms of
macro expansion no longer always work.
∂21-Dec-83 2021 ALAN@MIT-MC must be wrong
Received: from MIT-MC by SU-AI with TCP/SMTP; 21 Dec 83 20:21:38 PST
Date: 21 December 1983 23:21 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: must be wrong
To: Guy.Steele @ CMU-CS-A
cc: common-lisp @ SU-AI
In-reply-to: Msg of 21 Dec 83 2153 EST () from Guy.Steele at CMU-CS-A
Date: 21 Dec 83 2153 EST (Wednesday)
From: Guy.Steele at CMU-CS-A
To recapitulate: ...
(LET* ((A B)
(B A))
(DECLARE (SPECIAL A B))
...)
Clearly both bindings should be special. Should either initializer
be special? Knotty problems lurk here, ...
They certainly do. I do not assert that I have an answer to this problem
that I think is acceptable to introduce into Common Lisp at this point. I
do think that the current situation is quite clearly broken. (Moon's
recent proposal makes me least unhappy, but that is not the same things as
happyness.)
In the example above I see two variables named A and two variables named B.
Each variable occurs exactly once in the fragment (ignoring the DECLARE).
You assert that according to Mary Poppins (!) the special declaration
refers to all four occurences, even though only two names are mentioned in
the DECLARE. I claim that this is ugly and a symptom of a confusion
between variables, and occurrences of the names of variables. I would like
special declarations to allow me to talk about variables themselves, not
about occurrences of their names. Moon's proposal at least has the feature
that if I know where a variable is bound I can attach declarations to the
variable itself.
∂22-Dec-83 2221 @MIT-MC:Benson%SPA-NIMBUS@MIT-MC Unrelated issue re: special declarations
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Dec 83 22:21:36 PST
Received: from SCRC-ANNISQUAM by SCRC-QUABBIN with CHAOS; Fri 23-Dec-83 01:15:15-EST
Date: Fri, 23 Dec 83 01:19 EST
From: <Benson%SPA-NIMBUS@MIT-MC.ARPA>
Subject: Unrelated issue re: special declarations
To: common-lisp@SU-AI.ARPA
Is it true that it was a design decision rather than an oversight that
there is no UNSPECIAL declaration? I seem to remember this had
something to do with making the interpreter easier, avoiding the need
for BLINTZ vectors or such. If this is in fact the case, it should be
mentioned in the manual. If it is a part of the language design, there
are several consequences.
An implementation which includes an UNSPECIAL declaration is violating
the standard, not extending it. Portable code analysis programs must
make some assumptions about the semantics of the code they are looking
at.
It is legitimate for a macro to substitute the value of a symbol defined
by DEFCONSTANT (assuming EQLness is preserved), since they are
proclaimed special and cannot be shadowed by an UNSPECIAL declaration.
Notice this depends critically on the previous statement.
∂23-Dec-83 0510 GSB@MIT-MC Unrelated issue re: special declarations
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Dec 83 05:10:26 PST
Date: 23 December 1983 08:10 EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: Unrelated issue re: special declarations
To: Benson @ SPA-NIMBUS
cc: common-lisp @ SU-AI
I'm too burned out now to recreate any arguments, but as i remember
it even with blintz vectors i was perfectly pleased to eliminate
the unspecial declaration, and doing so was one of the first ways
i changed the nil interpreter to be common-lisp compatible wrt declarations.
I've got the implementation details of this, including explanation
of exactly the simplifications i could make by eliminating unspecial,
written down somewhere and will dig them up if necessary.
∂27-Dec-83 2151 @MIT-ML:Moon%SCRC-TENEX@MIT-MC single-float-epsilon
Received: from MIT-ML by SU-AI with TCP/SMTP; 27 Dec 83 21:51:46 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 28-Dec-83 00:52:56-EST
Date: Wed, 28 Dec 83 00:47 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: single-float-epsilon
To: Steele%Tartan@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Sorry I didn't notice this before, but I'm not sure that the definition
of single-float-epsilon given in the manual is really what you intended.
Specifically, on most machines (those that do rounding to nearest) this
number is -not- a power of 2, rather it is one unit in the least significant
place more than a power of 2. I would think that most applications of
this would prefer to have a power of 2.
Is it possible that the definition you wanted was "the largest positive
floating-point number e such that the expression
(= (float 1 e) (+ (float 1 e) e))
is false when actually evaluated."?
In the meantime I've fixed our implementation to conform to the manual
instead of having a value that was off by a hair less than a power of 2
(the person computing the value clearly must have assumed that it was
meant to be a power of 2 and didn't consider other numbers).
∂27-Dec-83 2152 @MIT-ML:Moon%SCRC-TENEX@MIT-MC single-float-epsilon
Received: from MIT-ML by SU-AI with TCP/SMTP; 27 Dec 83 21:52:13 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Wed 28-Dec-83 00:53:36-EST
Date: Wed, 28 Dec 83 00:48 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: single-float-epsilon
To: Steele%Tartan@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA
This message supersedes previous copies; please forgive the duplication.
Sorry I didn't notice this before, but I'm not sure that the definition
of single-float-epsilon given in the manual is really what you intended.
Specifically, on most machines (those that do rounding to nearest) this
number is -not- a power of 2, rather it is one unit in the least significant
place more than a power of 2. I would think that most applications of
this would prefer to have a power of 2.
Is it possible that the definition you wanted was "the largest positive
floating-point number e such that the expression
(= (float 1 e) (+ (float 1 e) e))
is false when actually evaluated."?
In the meantime I've fixed our implementation to conform to the manual
instead of having a value that was off by a factor of a hair less than 2
(the person computing the value clearly must have assumed that it was
meant to be a power of 2 and didn't consider other numbers).
∂29-Dec-83 1902 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Query about UNION
Received: from MIT-ML by SU-AI with TCP/SMTP; 29 Dec 83 19:02:27 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Thu 29-Dec-83 22:01:00-EST
Date: Thu, 29 Dec 83 22:00 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Query about UNION
To: Common-Lisp@SU-AI.ARPA
The Mary Poppins manual does not make clear whether UNION is permitted to
share structure with one of its arguments. For example, a possible
implementation technique (assuming for clarity that all keyword arguments
default) would be:
(defun union (list1 list2)
(dolist (item list2)
(unless (member item list1)
(push item list1)))
list1)
Is this permissible or impermissible? Near the top of page 202 the manual
says "returns a new list", and "new" may mean that every cons in the backbone
of the list is newly-created, or it might mean simply that the list is
the result of a computation.
A related query applies to the other three non-destructive set-construction
operations: if their result is to be EQUAL to one of their arguments, or some
nthcdr of one of their arguments, are they permitted to return the argument,
or the tail of it, or are they guaranteed always to return a freshly-constructed
list?
∂30-Dec-83 1445 @MIT-ML:Moon%SCRC-TENEX@MIT-MC query about make-broadcast-stream
Received: from MIT-ML by SU-AI with TCP/SMTP; 30 Dec 83 14:45:26 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Fri 30-Dec-83 17:47:25-EST
Date: Fri, 30 Dec 83 17:45 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: query about make-broadcast-stream
To: Common-Lisp@SU-AI.ARPA
What does the last phrase in the description of make-broadcast-stream
("every operation results in nil") mean? This phrase was not present in
the Excelsior edition. The values returned by the Common Lisp stream
functions are defined with each function and are not up to the stream.
There isn't (in Common Lisp) anything else that could be called an
"operation."
∂30-Dec-83 1605 KMP@MIT-MC
Received: from MIT-MC by SU-AI with TCP/SMTP; 30 Dec 83 16:02:54 PST
Date: 30 December 1983 18:48 EST
From: Kent M Pitman <KMP @ MIT-MC>
To: Common-Lisp @ SU-AI
In-Reply-To: The message of Thu, 29 Dec 83 22:00-EST from "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
If this is really still subject to interpretation, I encourage the
shared-structure approach.
For the simple cases, it would be best not to scare people away from
using these set operations because they believe them to be too
inefficient. Odds are you wouldn't feel as bad about the possible
redundant consing in (COPYLIST (UNION X Y)) if you need a full copy
as you would feel about the unnecessary consing in (UNION X Y) if you
didn't want a full copy.
In general, I think the burden should be on those who want to do
side-effects to assure that they have taken appropriate safety
precautions.
Also, writing (COPYLIST (UNION X Y)) makes an important assumption
explicit in the code. If (UNION X Y) is always copying, it is harder to
tell from inspection when the programmer plans to take advantage of
the fact.
-kmp
∂30-Dec-83 1621 FAHLMAN@CMU-CS-C.ARPA Union and friends
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 30 Dec 83 16:21:41 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 30 Dec 83 19:22:46-EST
Date: Fri, 30 Dec 1983 19:22 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Union and friends
In-reply-to: Msg of 30 Dec 1983 18:48 EST from Kent M Pitman <KMP at MIT-MC>
I agree with KMP that Union and friends would be much more useful if
shared substructure is allowed. Usually you want the efficiency and
don't care about the purity of the list, and if you do care you can copy
the list with little loss of efficiency. (Note that NUNION and friends
are still different, in that they allow the arguments to be clobbered
and not merely shared.) Despite this preference, I note that whoever
implemented our version of UNION interpreted the manual as requiring a
fresh copy. In any event, a clarification is needed.
-- Scott
∂30-Dec-83 2144 Guy.Steele@CMU-CS-A UNION and friends
Received: from CMU-CS-A by SU-AI with TCP/SMTP; 30 Dec 83 21:44:19 PST
Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 31 Dec 83 00:28:58 EST
Date: 31 Dec 83 0042 EST (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: UNION and friends
I had intended that UNION and friends be able to share structure
and not be required to make completely fresh lists. This is in
line with many of the non-destructive sequence functions. I will
clarify this in the prose for publication.
∂02-Jan-84 0903 FAHLMAN@CMU-CS-C.ARPA query about make-broadcast-stream
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Jan 84 09:03:04 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 2 Jan 84 12:02:58-EST
Date: Mon, 2 Jan 1984 12:02 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: query about make-broadcast-stream
In-reply-to: Msg of 30 Dec 1983 17:45-EST from "David A. Moon" <Moon%SCRC-TENEX at MIT-MC.ARPA>
From Moon:
What does the last phrase in the description of make-broadcast-stream
("every operation results in nil") mean? This phrase was not present in
the Excelsior edition. The values returned by the Common Lisp stream
functions are defined with each function and are not up to the stream.
There isn't (in Common Lisp) anything else that could be called an
"operation."
Since nobody else has popped up to answer this question, I'll try. It
seems very clear to me that the "every operation results in NIL"
business is a slip-up and should not be there. In case there is not
really an output stream you want all output to be discarded, but write
operations should return whatever they would normally return. Perhaps
Guy was trying to say that any operation whose return value is undefined
if there is no real stream, such as STREAM-ELEMENT-TYPE, would return
NIL for this type of stream.
If Guy really intends this phrase to be taken seriously, which implies
special-casing every stream operation to handle this case, then some more
motivation and discussion is needed. In the absence of such, we are
treating this as an error.
-- Scott
∂02-Jan-84 0941 KMP@MIT-MC Sad historical sidelights: Return values -- NIL vs undefined
Received: from MIT-MC by SU-AI with TCP/SMTP; 2 Jan 84 09:41:31 PST
Date: 2 January 1984 12:42 EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Sad historical sidelights: Return values -- NIL vs undefined
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
References: Msg of 30 Dec 83 17:45-EST from "David A. Moon" <Moon%SCRC-TENEX at MIT-MC.ARPA>
In-reply-to: Msg of Mon 2 Jan 1984 12:02 EST from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Mon, 2 Jan 1984 12:02 EST
From: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
... If Guy really intends this phrase to be taken seriously, which implies
special-casing every stream operation to handle this case, then some more
motivation and discussion is needed. In the absence of such, we are
treating this as an error...
Looking at people's code over the years, I've noticed (as I'm sure others
have) it's generally much better to leave undefined values explicitly
undefined rather than to say NIL is returned. Not only does it cause the
compiler to do extra work and produce shoddier code, but I have actually
seen people write things like:
(AND (PRED1 X)
(NOT (TERPRI))
(PRINC FOO)
(PRED2 X))
I've seen real Maclisp code that did this sort of silliness. Whenever you
needlessly define return values for things, you just set yourself up for
bitching from people who've taught themselves to depend on things they
should never have even considered using in the first place.
In general, I would say the return value of no function, operation, or
whatever should be defined unless we are prepared to be happy with people
picking up and using that value shamelessly.
∂02-Jan-84 1227 @MIT-ML:Moon%SCRC-TENEX@MIT-MC query about make-broadcast-stream
Received: from MIT-ML by SU-AI with TCP/SMTP; 2 Jan 84 12:26:52 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Mon 2-Jan-84 15:20:04-EST
Date: Mon, 2 Jan 84 15:26 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: query about make-broadcast-stream
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
In-reply-to: The message of 2 Jan 84 12:02-EST from Scott E. Fahlman <Fahlman at CMU-CS-C>
Date: Mon, 2 Jan 1984 12:02 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
From Moon:
What does the last phrase in the description of make-broadcast-stream
("every operation results in nil") mean? This phrase was not present in
the Excelsior edition. The values returned by the Common Lisp stream
functions are defined with each function and are not up to the stream.
There isn't (in Common Lisp) anything else that could be called an
"operation."
Since nobody else has popped up to answer this question, I'll try. It
seems very clear to me that the "every operation results in NIL"
business is a slip-up and should not be there. In case there is not
really an output stream you want all output to be discarded, but write
operations should return whatever they would normally return. Perhaps
Guy was trying to say that any operation whose return value is undefined
if there is no real stream, such as STREAM-ELEMENT-TYPE, would return
NIL for this type of stream.
It seems clear to me that if it is defined at all, STREAM-ELEMENT-TYPE of
such a stream should be (AND), otherwise known as T. It's the intersection
of the stream-element-types of the streams it broadcasts to.
If Guy really intends this phrase to be taken seriously, which implies
special-casing every stream operation to handle this case, then some more
motivation and discussion is needed. In the absence of such, we are
treating this as an error.
I agree with you. In our implementation (make-broadcast-stream) returns
a stream that accepts all output and throws it away.
∂03-Jan-84 1417 @MIT-ML:MOON@SCRC-TENEX Order of arguments to :test functions
Received: from MIT-ML by SU-AI with TCP/SMTP; 3 Jan 84 14:16:46 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 3-Jan-84 17:17:41-EST
Date: Tuesday, 3 January 1984, 17:17-EST
From: <MOON at SCRC-TENEX>
Subject: Order of arguments to :test functions
To: Steele%Tartan at cmu-cs-c
Cc: Common-Lisp at su-ai
p.209: I assume it is intended that remove-duplicates and delete-duplicates
will not change the order of elements in the sequence, unlike intersection
(for example). This is implied but not stated explicitly. It's particularly
important when the :test function is something that is not commutative,
subtypep to take a real example.
Of course the ability to use subtypep as a :test function also relies on
a reading of pp.202-203 that may perhaps be stricter than what you intended.
In our implementation the order of arguments to the test function is
always strictly guaranteed; informally the rule is "the order of arguments
to the test function is the same as the order of arguments to the original
function." For things that take one sequence argument and compare
two elements of that sequence, e.g. remove-duplicates, the order of arguments
to the test function is the same as the order of elements in the sequence.
The manual might want to take a stronger stand on this, or else state clearly
that it does not take a stand on this. Users will rely on anything they discover
about an implementation that they aren't explicitly told not to rely on.
Actually I think guaranteeing the order of arguments to the :test function
is quite worthwhile.
∂03-Jan-84 1556 @MIT-ML:MOON@SCRC-TENEX Proposed new type expression
Received: from MIT-ML by SU-AI with TCP/SMTP; 3 Jan 84 15:56:22 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 3-Jan-84 17:37:05-EST
Date: Tuesday, 3 January 1984, 17:36-EST
From: <MOON at SCRC-TENEX>
Subject: Proposed new type expression
To: Common-Lisp at su-ai
Here is an extension to the Common Lisp type system that people might
want to keep in mind. It didn't take me very long to implement this
(10 minutes plus about 3 hours of improvements to the type implementation
that I got stimulated to do while looking at it).
(DECLARE <type>) is a type expression that can be used for discrimination.
It treats <type> the way it would be treated for declaration, instead
of the normal way it is treated for discrimination. For most types this
makes no difference, but for ARRAY and COMPLEX types, and types built on
them such as VECTOR, it does make a difference and furthermore it hides
implementation-dependent knowledge of what specialized types are provided
by the particular implementation.
<type> cannot be (FUNCTION ...) [although I think an implementation could
provide this as an extension if it has the ability to check arg/value types.]
Example of use:
(defun foo (image)
(declare (type (array (signed-byte 12)) image))
(when *enable-type-checking*
(check-type image (declare (array (signed-byte 12)))))
...)
In an implementation that has only the minimum specialized arrays required by
Common Lisp, (DECLARE (ARRAY (SIGNED-BYTE 12))) is equivalent to (ARRAY T)
while (ARRAY (SIGNED-BYTE 12)) is equivalent to NIL. In another
implementation that has specialized arrays of 16-bit twos-complement integers,
(DECLARE (ARRAY (SIGNED-BYTE 12))) is equivalent to (ARRAY (SIGNED-BYTE 16))
but (ARRAY (SIGNED-BYTE 12)) is still equivalent to NIL. In a third
implementation that has specialized arrays of 12-bit twos-complement integers,
(DECLARE (ARRAY (SIGNED-BYTE 12))) and (ARRAY (SIGNED-BYTE 12)) are
equivalent.
∂03-Jan-84 2010 FAHLMAN@CMU-CS-C.ARPA Proposed new type expression
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 3 Jan 84 20:09:58 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 3 Jan 84 23:10:40-EST
Date: Tue, 3 Jan 1984 23:10 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: <MOON%SCRC-TENEX@MIT-ML.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Proposed new type expression
In-reply-to: Msg of 3 Jan 1984 17:36-EST from <MOON at SCRC-TENEX>
It looks to me like this fills a real need and does so rather elegantly.
I think this would be a useful thing to include in the second edition,
and maybe to adopt as an informal standard before that, if any mechanism
for doing this is set up. I don't much like the looks of DECLARE in
this role, but at present I have nothing better to propose. It does
have a certain logic to it.
-- Scott
∂05-Jan-84 0711 jrg@cmu-cs-spice extending or correcting common lisp
Received: from CMU-CS-SPICE by SU-AI with TCP/SMTP; 5 Jan 84 07:11:44 PST
Date: Thursday, 5 January 1984 09:11:36 EST
From: Joseph.Ginder@CMU-CS-SPICE
To: common-lisp@su-ai
Subject: extending or correcting common lisp
Message-ID: <1984.1.5.13.59.28.Joseph.Ginder@CMU-CS-SPICE>
How are we going to distribute info. about such things as Moon's type
description proposal between manual editions? Moon's type stuff, in
particular, seems like an important correction to the spec (we really should
have done something like that to start with). I assume it's too late for
inclusion in the first edition of the manual, but too important to hold off
until the second. Is the rumored "Common Lisp Institute" or whatever really
going to happen? Will it do this sort of thing?
--Joe
∂05-Jan-84 1805 GREEK@DEC-MARLBORO.ARPA A nit and a suggestion for the future.
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 5 Jan 84 18:05:41 PST
Date: Thu 5 Jan 84 21:00:58-EST
From: GREEK@DEC-MARLBORO.ARPA
Subject: A nit and a suggestion for the future.
To: common-lisp@SU-AI.ARPA
First the nit. What happened to the proposal that the time zone ought
to be a rational so that folks in Newfoundland will be happy?
A suggestion for future enhancements to DEFSTRUCT. There is no way
to attach doc strings to anything but the structure itself. I can't
hang a doc string on the accessors, SETF forms, print function, copier,
etc. I'm afraid DEFSTRUCT needs a host of additional options.
Does anyone have a good idea for a return value from SET-SYNTAX-FROM-CHAR?
- Paul
-------
∂08-Jan-84 1806 @MIT-MC:PGS%MIT-OZ@MIT-MC suggestion for the future.
Received: from MIT-MC by SU-AI with TCP/SMTP; 8 Jan 84 18:06:23 PST
Date: Sun, 8 Jan 1984 21:01 EST
Message-ID: <PGS.11982100150.BABYL@MIT-OZ>
From: PGS%MIT-OZ@MIT-MC.ARPA
To: GREEK@DEC-MARLBORO.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: suggestion for the future.
In-reply-to: Msg of 5 Jan 1984 21:00-EST from GREEK at DEC-MARLBORO.ARPA
Date: Thursday, 5 January 1984 21:00-EST
From: GREEK at DEC-MARLBORO.ARPA
To: common-lisp at SU-AI.ARPA
Re: A nit and a suggestion for the future.
...A suggestion for future enhancements to DEFSTRUCT. There is no way
to attach doc strings to anything but the structure itself. I can't
hang a doc string on the accessors, SETF forms, print function, copier,
etc. I'm afraid DEFSTRUCT needs a host of additional options.
I think that documenting the slots themselves, as opposed to documenting
anything that was generated automatically (especially the vanilla print
handler), is more like what one would want to do. The documentation strings
for slots could be printed by DESCRIBE, and the accessor could have a
documentation string created from the slot description. The documentation
string could be specified as a third object in each slot description:
(defstruct (elephant :conc-name)
(color 'GRAY
"The elephant's color, should be one of GRAY, BROWN, or PINK.")
...)
The documentation string for ELEPHANT-COLOR could look like:
"The accessor for the COLOR slot of the ELEPHANT structure.
The COLOR slot's documentation is:
The elephant's color, should be one of GRAY, BROWN, or PINK."
∂09-Jan-84 1144 GREEK@DEC-MARLBORO.ARPA Doc Strings for DEFSTRUCT
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 9 Jan 84 11:44:19 PST
Date: Mon 9 Jan 84 14:40:12-EST
From: GREEK@DEC-MARLBORO.ARPA
Subject: Doc Strings for DEFSTRUCT
To: common-lisp@SU-AI.ARPA
Concerning doc strings for structure slots:
You might want to add that feature also, although I'd rather document
slots in the main documentation for the structure. You'll have
difficulty in integrating that into the DOCUMENTATION function.
I want to document the generated functions because I don't want the
user to know the thing is implemented as a structure. For example,
any common data type implemented as a structure falls into that
category. They just look like functions.
I suggest we not add a doc string for the print function, as the user
doesn't often call it directly.
- Paul
-------
∂09-Jan-84 1212 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Documenting defstruct slots
Received: from MIT-ML by SU-AI with TCP/SMTP; 9 Jan 84 12:04:37 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Mon 9-Jan-84 15:08:50-EST
Date: Mon, 9 Jan 84 15:01 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Documenting defstruct slots
To: PGS%MIT-OZ@MIT-MC.ARPA
Cc: GREEK@DEC-MARLBORO.ARPA, common-lisp@SU-AI.ARPA
In-reply-to: <PGS.11982100150.BABYL@MIT-OZ>
Date: Sun, 8 Jan 1984 21:01 EST
From: PGS%MIT-OZ@MIT-MC.ARPA
I think that documenting the slots themselves, as opposed to documenting
anything that was generated automatically (especially the vanilla print
handler), is more like what one would want to do. The documentation strings
for slots could be printed by DESCRIBE, and the accessor could have a
documentation string created from the slot description. The documentation
string could be specified as a third object in each slot description:
(defstruct (elephant :conc-name)
(color 'GRAY
"The elephant's color, should be one of GRAY, BROWN, or PINK.")
...)
The documentation string for ELEPHANT-COLOR could look like:
"The accessor for the COLOR slot of the ELEPHANT structure.
The COLOR slot's documentation is:
The elephant's color, should be one of GRAY, BROWN, or PINK."
This is fine, but is not the syntax of Common Lisp defstruct. If you don't
have a copy of the Common Lisp manual (Mary Poppins edition) you should obtain
one.
∂09-Jan-84 1231 KMP@MIT-MC Structures, documentation
Received: from MIT-MC by SU-AI with TCP/SMTP; 9 Jan 84 12:30:34 PST
Date: 9 January 1984 15:31 EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Structures, documentation
To: PGS @ MIT-OZ
cc: Common-Lisp @ SU-AI
References: <PGS.11982100150.BABYL@MIT-OZ>,
Msg of 5 Jan 1984 21:00-EST from GREEK at DEC-MARLBORO.ARPA
This message is speculative. I doubt if it's something we're in a position
to do right now with the manual frozen and all, but i figured it was worth
laying on the table anyway...
Date: Sun, 8 Jan 1984 21:01 EST
From: PGS%MIT-OZ at MIT-MC.ARPA
To: GREEK at DEC-MARLBORO.ARPA
cc: common-lisp at SU-AI.ARPA
... The documentation strings for slots could be printed by DESCRIBE,
and the accessor could have a documentation string created from the
slot description. The documentation string could be specified as a
third object in each slot description:
(defstruct (elephant :conc-name)
(color 'GRAY
"The elephant's color, should be one of GRAY, BROWN, or PINK.")
...)
The documentation string for ELEPHANT-COLOR could look like:
"The accessor for the COLOR slot of the ELEPHANT structure.
The COLOR slot's documentation is:
The elephant's color, should be one of GRAY, BROWN, or PINK."
Well, it's certainly outside of Common Lisp's domain to dictate the
specifics of what gets printed, but just to let me rest easier, let me
point out that nothing bothers me more than little noise lines like the
middle one above. I would prefer to see something more like
"The accessor for the COLOR slot of the ELEPHANT structure:
The elephant's color, should be one of GRAY, BROWN, or PINK."
When you have to get 50 of them printed out for a structure, you get
bored with the one that doesn't provide additional bits.
Anyway, it's also the case that you cannot do anything useful mechanically
with this comment string. It would be very nice if this sort of thing could
provide data in a form that programs could manipulate. I would recommend
the following kinds extensions:
* Specify something about the shape of the documentation string.
For example, should fit in a noun phrase after a determiner such
as "the" or "this". In normal circumstances, the string should be
in lower case so it will fit naturally into sentences.
Examples: "elephant", "space ship", "red box".
This would allow FORMAT calls like:
(format t "Select another ~A from the menu" ...)
(format t "Do you want me to describe this ~A?")
* Specify that the slot documentation should not mention the thing of
which it is a part. That way, if you :include one struct into another,
you get more abstract slot documentation.
* Specify the fillers as objects. This allows one to distinguish objects
with the same printed representation (eg, symbols on differing packages,
etc). Possibly also specify an alist of names.
This sort of constraint will allow one to interface nicely to things akin
to the LispM's TV:CHOOSE-VARIABLE-VALUES, for example. The result would
be something like:
(defstruct (elephant :conc-name
(:include four-legged-mammal)
(:documentation "elephant"))
(color `COLOR:GRAY "color" '(("gray" . ,COLOR:GRAY)
("brown" . ,COLOR:BROWN)
("pink" . ,COLOR:PINK))))
ELEPHANT
(describe (make-elephant color color:pink))
The elephant #<ELEPHANT-37> has the following features:
Its color is pink.
Its number of legs is 3.
Its name is Clyde.
(describe-structure 'elephant)
An instance of elephant has 3 properties.
Its color may be gray, brown, or pink.
Its number of legs may be any positive integer.
Its name may be a string.
(describe-structure 'elephant :show-internals t)
An instance of ELEPHANT has 3 slots:
The COLOR slot holds its color, which may be one of:
COLOR:GRAY, COLOR:BROWN, COLOR:PINK
The N-LEGS slot (inherited from structure type FOUR-LEGGED-MAMMAL)
holds its number of legs, which may be any positive integer.
The NAME slot (inherited from structure ANIMAL)
holds its name, which may be a string.
(edit-structure-instance-with-menu (make-elephant))
The object being edited is #<ELEPHANT-38>.
Use the mouse to select new values:
Color: gray brown PINK
Number of legs: 3
Name: Clyde
The point of this last example is not to say these are the operations or
formats I would like to see so much as to say that with just a little more
specification of the form of the documentation in the struct, you can
achieve a much more flexible output format.
∂10-Jan-84 2047 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Questions about COERCE
Received: from MIT-ML by SU-AI with TCP/SMTP; 10 Jan 84 20:47:27 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 10-Jan-84 23:46:32-EST
Date: Tue, 10 Jan 84 23:47 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Questions about COERCE
To: Common-Lisp@SU-AI.ARPA
Are the following examples of calls to COERCE legal, illegal, or permissible
but not required extensions? The manual isn't very explicit on this point.
(coerce '(1 2 3) '(vector t 3)) ;length specified
(coerce '(1 2 3) '(vector t 4)) ;length specified and doesn't match
(coerce x '(array single-float 2)) ;not a subtype of sequence
(coerce #\A 'string-char) ;subtype of character
(coerce #\c-A 'string-char) ;type mismatch: error or discard bits?
(coerce 22/7 '(float 0 10)) ;range specified
Currently each of these expressions signals an error in our implementation,
although none of them would be difficult to implement if I knew what they
were supposed to do. It's okay with me to leave them illegal.
∂11-Jan-84 0813 FAHLMAN@CMU-CS-C.ARPA Questions about COERCE
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 11 Jan 84 08:13:32 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 11 Jan 84 11:14:08-EST
Date: Wed, 11 Jan 1984 11:14 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Questions about COERCE
In-reply-to: Msg of 10 Jan 1984 23:47-EST from "David A. Moon" <Moon%SCRC-TENEX at MIT-MC.ARPA>
I believe that we currently treat all of your examples as errors also.
Coerce says it will do certain particular conversions, and that's all we
provided, using a narrow reading for such phrases as "other sequence
type".
Since Coerce pretty much has to be coded as an N*M dispatch (with some
few opportunities for folding), and all of those dispatch cases want to
be optimized at compile-time if the args are of known type, we would
really like to keep M reasonably small. So I argue that we should use
COERCE just to move between major types, as enumerated in the manual,
and should use more specific functions to change the length of vectors
or trim off control bits. If we try to make coerce be the universal
unary operator, we're going to need DEFCOERCE and god knows what else.
-- Scott
∂11-Jan-84 1721 GREEK@DEC-MARLBORO.ARPA COERCE
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 11 Jan 84 17:20:39 PST
Date: Wed 11 Jan 84 20:21:27-EST
From: GREEK@DEC-MARLBORO.ARPA
Subject: COERCE
To: common-lisp@SU-AI.ARPA
I agree with Scott that we could open a real can of worms here.
If COERCE is generalized, then DEFTYPE needs a whole new hack
to allow the specification of how objects of the new type are
coerced to other types. And that means that DEFSTRUCT needs
the same extension. Let's just drop it now.
- Paul
-------
∂17-Jan-84 1835 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Query about definition of COMMON data type
Received: from MIT-ML by SU-AI with TCP/SMTP; 17 Jan 84 18:35:03 PST
Received: from SCRC-EUPHRATES by SCRC-TENEX with CHAOS; Tue 17-Jan-84 21:33:21-EST
Date: Tue, 17 Jan 84 21:20 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Query about definition of COMMON data type
To: Steele%Tartan@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA
A strict reading of the last two paragraphs on page 28 of the Mary Poppins
edition says that STRING is not a subtype of COMMON. This is because STRING
is (ARRAY STRING-CHAR 1), and STRING-CHAR is neither T nor a subtype of
COMMON. STANDARD-CHAR is a subtype of COMMON, but STRING-CHAR is not, and
is not necessarily a subtype of STANDARD-CHAR.
I assume this was not intentional, and STRING should be a subtype of
COMMON for the same reason that (ARRAY T) is a subtype of COMMON. I agree
that STRING-CHAR should not be a subtype of COMMON; that makes sense.
∂12-Jan-84 0809 FAHLMAN@CMU-CS-C.ARPA Flavors
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jan 84 08:09:23 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 12 Jan 84 11:09:39-EST
Date: Thu, 12 Jan 1984 11:09 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: moon%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA,
hic%SCRC-TENEX@MIT-ML.ARPA
Cc: rpg@SU-AI.ARPA, steele%tartan@CMU-CS-C.ARPA, gbrown@DEC-MARLBORO.ARPA,
vanroggen@CMU-CS-C.ARPA
Subject: Flavors
We have talked in the past about getting a portable flavor package done
in Common Lisp (with whatever minimal set of some non-portable support
is necessary for decent performance). The default assumption has always
been that you folks would do this, because that's the best way of
getting it done (a) right and (b) without minor incompatibilites with
the 3600 flavor system. However, you folks clearly have some
higher-priority tasks on your queue, and it kinda looks to me like that
is not going to change in the forseeable future.
I have a pretty good programmer, and maybe a second one, who are getting
really interested in having flavors up, and would like to go ahead and
do this if you folks are not going to do it fairly soon. Obviously,
this would come out better for all concerned if we have good access to
your flavor-system code and your active cooperation. I think our best
move would be to try to bring up something as compatible with the 3600
flavor system as possible, and save any "obvious improvements" for
later, after discussion. I fear that if you don't do this and we don't,
some bozo out in user-land will try and will botch the job. Any
thoughts?
Also, if anyone there wants to specify what a really good LOOP package
would look like, or even send us some notes on what you think is
wrong with the current one, we'll probably get around to implementing
that as well (if we like what we see). Since I have never used such a
system and have only recently decided that one would be useful, I am not
the right one to try to specify this -- I'll make all the rookie
mistakes. But given a specification, we can probably get it coded over
the next few months.
Now that we're wrapping up the implementation effort for Common Lisp
proper, I've got a few good programmers looking for new assignments --
hence the sudden interest in doing some of the things we've all put off.
(No, I don't have anyone who wants to do the transcendental/complex
stuff -- Guy is the only person I know who gets turned on by that kind
of hackery, and he's tied up.)
-- Scott
∂12-Jan-84 1554 @MIT-ML:HIC%SCRC-TENEX@MIT-MC Flavors
Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Jan 84 15:54:38 PST
Date: Thu, 12 Jan 84 15:53 PST
From: HIC%SCRC-TENEX@MIT-MC.ARPA
Sender: FILE-SERVER%SWW-WHITE@MIT-MC.ARPA
Subject: Flavors
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>,
moon%SCRC-TENEX@MIT-MC.ARPA, dlw%SCRC-TENEX@MIT-MC.ARPA,
hic%SCRC-TENEX@MIT-MC.ARPA
Cc: rpg@SU-AI.ARPA, steele%tartan@CMU-CS-C.ARPA,
gbrown@DEC-MARLBORO.ARPA, vanroggen@CMU-CS-C.ARPA
12-Jan-84 11:15:24-EST,2605;000000000001
Return-path: <Mailer@SCRC-TENEX>
Received: from MIT-ML by SCRC-TENEX with CHAOS; Thu 12-Jan-84 11:12:04-EST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 12 Jan 84 11:09:39-EST
Date: Thu, 12 Jan 1984 11:09 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: moon%SCRC-TENEX@MIT-ML.ARPA, dlw%SCRC-TENEX@MIT-ML.ARPA,
hic%SCRC-TENEX@MIT-ML.ARPA
Cc: rpg@SU-AI.ARPA, steele%tartan@CMU-CS-C.ARPA, gbrown@DEC-MARLBORO.ARPA,
vanroggen@CMU-CS-C.ARPA
Subject: Flavors
We have talked in the past about getting a portable flavor package done
in Common Lisp (with whatever minimal set of some non-portable support
is necessary for decent performance). The default assumption has always
been that you folks would do this, because that's the best way of
getting it done (a) right and (b) without minor incompatibilites with
the 3600 flavor system. However, you folks clearly have some
higher-priority tasks on your queue, and it kinda looks to me like that
is not going to change in the forseeable future.
I have a pretty good programmer, and maybe a second one, who are getting
really interested in having flavors up, and would like to go ahead and
do this if you folks are not going to do it fairly soon. Obviously,
this would come out better for all concerned if we have good access to
your flavor-system code and your active cooperation. I think our best
move would be to try to bring up something as compatible with the 3600
flavor system as possible, and save any "obvious improvements" for
later, after discussion. I fear that if you don't do this and we don't,
some bozo out in user-land will try and will botch the job. Any
thoughts?
This is wonderful news!
As you know, I have the start of the proposal. I suspect we can work from that.
Invite me to CMU, and I'll spend the few days necessary to get your guys
started. Better yet, send a few people out to sunny, WARM, Westwood
California...
It might be possible to arrange to give you the Flavor code from our
system, if we got back a Flavor implementation that worked in terms of
the Common lisp primitives. Another possibility is to "do it right,"
and fix some of the big problems that I've wanted to do a new
reimplementation for.
In any case, let's talk soon!!!
∂12-Jan-84 1838 FAHLMAN@CMU-CS-C.ARPA Flavors
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jan 84 18:38:42 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 12 Jan 84 21:39:04-EST
Date: Thu, 12 Jan 1984 21:38 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: HIC%SCRC-TENEX@MIT-MC.ARPA
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, gbrown@DEC-MARLBORO.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA, steele%tartan@CMU-CS-C.ARPA,
vanroggen@CMU-CS-C.ARPA, fahlman@CMU-CS-C.ARPA
Subject: Flavors
In-reply-to: Msg of 12 Jan 1984 18:53-EST from HIC%SCRC-TENEX at MIT-MC.ARPA
Howard,
Glad to hear you're eager to cooperate. That will help a lot.
Unfortunately, I don't think we have any way to fund a trip for my
undergrad hackers out to California -- it's tricky enough to find travel
money for faculty. As for you coming here, you're always welcome to
visit. I can probably find some travel-expense money somewhere, but it
will take me a little while to figure out where. Also, we will have to
figure out when the optimal time for a visit would be.
The hackers in question have a few other things to finish up before they
can really get into this, but they can start reading and thinking about
the problem in background mode right away. I assume that you have no
objection to my showing them that draft proposal you sent out way back
whenever it was? At the time you were sort of reticent about this. I
think I've still got it on disk if the bit-weevils haven't struck. Any
thoughts you might have about what needs to be fixed should probably be
sketched out in advance of any coding -- even if we decide to wait till
later for improvements, we would benefit from knowing what hooks to put
in.
Whatever Common Lisp code we produce for this will have to go into the
Common Lisp yellow pages so that all Common Lisp implementations can use
it. The whole point is to do this just once, and do it right. It would
be best if we had Symbolics' official permission to adapt their code for
this purpose and to make the result public-domain. If the lawyers can't
swallow that, we could probably just write our own public-domain version
from the ground up (after a few furtive glances at the Lisp Machine
sources). The point would not be to swipe anything from Symbolics --
RMS "liberation" mode is not really our style -- but just to keep the
lawyers out of the act, while still ending up with as compatible a
system as possible.
-- Scott
∂12-Jan-84 2011 @MIT-ML:hic%SCRC-TENEX@MIT-MC Flavors
Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Jan 84 20:11:24 PST
Date: Thu, 12 Jan 84 20:09 PST
From: hic%SCRC-TENEX@MIT-MC.ARPA
Sender: FILE-SERVER%SWW-WHITE@MIT-MC.ARPA
Subject: Flavors
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>,
HIC%SCRC-TENEX@MIT-MC.ARPA
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, gbrown@DEC-MARLBORO.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA,
steele%tartan@CMU-CS-C.ARPA, vanroggen@CMU-CS-C.ARPA,
fahlman@CMU-CS-C.ARPA
In-reply-to: Your message
Howard,
Glad to hear you're eager to cooperate. That will help a lot.
Unfortunately, I don't think we have any way to fund a trip for my
undergrad hackers out to California -- it's tricky enough to find travel
money for faculty. As for you coming here, you're always welcome to
visit. I can probably find some travel-expense money somewhere, but it
will take me a little while to figure out where. Also, we will have to
figure out when the optimal time for a visit would be.
Well, that's OK. Don't worry about the travel expenses (and don't tell
anyone I said that!)
The hackers in question have a few other things to finish up before they
can really get into this, but they can start reading and thinking about
the problem in background mode right away. I assume that you have no
objection to my showing them that draft proposal you sent out way back
whenever it was? At the time you were sort of reticent about this. I
think I've still got it on disk if the bit-weevils haven't struck. Any
thoughts you might have about what needs to be fixed should probably be
sketched out in advance of any coding -- even if we decide to wait till
later for improvements, we would benefit from knowing what hooks to put
in.
I have no problem with you showing the draft around internally. I can
dig it up if you can't find it. We certainly do want to talk about
futures if a new implementation is to be started.
Whatever Common Lisp code we produce for this will have to go into the
Common Lisp yellow pages so that all Common Lisp implementations can use
it. The whole point is to do this just once, and do it right. It would
be best if we had Symbolics' official permission to adapt their code for
this purpose and to make the result public-domain. If the lawyers can't
swallow that, we could probably just write our own public-domain version
from the ground up (after a few furtive glances at the Lisp Machine
sources). The point would not be to swipe anything from Symbolics --
RMS "liberation" mode is not really our style -- but just to keep the
lawyers out of the act, while still ending up with as compatible a
system as possible.
-- Scott
I'll start checking internally to see what feelings are. It would be
nice to only do it once, and even nicer to get it right!
So, is the next action item telling me when a good time to show up is?
Are DLW and Moon in agreement with this plan? Do they want to join me
at CMU? (Is it 1985 yet...)
--Howard
∂12-Jan-84 2048 FAHLMAN@CMU-CS-C.ARPA Flavors
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 12 Jan 84 20:48:14 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 12 Jan 84 23:48:36-EST
Date: Thu, 12 Jan 1984 23:48 EST
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: hic%SCRC-TENEX@MIT-MC.ARPA
Cc: dlw%SCRC-TENEX@MIT-MC.ARPA, gbrown@DEC-MARLBORO.ARPA,
moon%SCRC-TENEX@MIT-MC.ARPA, rpg@SU-AI.ARPA, steele%tartan@CMU-CS-C.ARPA,
vanroggen@CMU-CS-C.ARPA
Subject: Flavors
In-reply-to: Msg of 12 Jan 1984 23:09-EST from hic%SCRC-TENEX at MIT-MC.ARPA
I guess the next action item on my side is for me to circulate your
proposal to the people who will be doing the work here, and to generally
get them started thinking about the implementation issues. I think we
have some Lisp sources around here for Flavor code (don't know how old),
and unless we hear objections, these guys will probably be taking a hard
look at that code as they gear up for this.
As I said, it will be at least two or three weeks, and maybe somewhat
more, before we're really ready to roll on this. Let me huddle with my
people here and decide who is really going to be assigned to this and
when they might want to start. My guess is that a visit in about a
month would be the best timing, but I'll get back to you once I have a
better picture of this. Are there any tight constraints on your end?
In the meantime, anything you want to write up on things that could be
done better next time would be most welcome. If we just talk about it,
a lot of what we discuss is likely to get lost.
-- Scott
∂12-Jan-84 2219 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Flavors
Received: from MIT-ML by SU-AI with TCP/SMTP; 12 Jan 84 22:18:53 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Fri 13-Jan-84 01:16:55-EST
Date: Fri, 13 Jan 84 01:16 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Flavors
To: hic%SCRC-TENEX@MIT-MC.ARPA
Cc: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>,
dlw%SCRC-TENEX@MIT-MC.ARPA, gbrown@DEC-MARLBORO.ARPA, rpg@SU-AI.ARPA,
steele%tartan@CMU-CS-C.ARPA, vanroggen@CMU-CS-C.ARPA
In-reply-to: The message of 12 Jan 84 23:09-EST from hic at SCRC-TENEX
Date: Thursday, 12 January 1984, 20:09-PST
From: hic at SCRC-TENEX
Are DLW and Moon in agreement with this plan? Do they want to join me
at CMU? (Is it 1985 yet...)
Yes, definitely I am. I don't think I'll have time, but keep me
informed. No, but it will be sooner than you think.
∂02-Feb-84 2127 @CMU-CS-C.ARPA:STEELE%TARTAN@CMU-CS-C.ARPA 1984 LISP Conference submissions deadline moved back
Received: from CMU-CS-C by SU-AI with TCP/SMTP; 2 Feb 84 21:27:06 PST
Received: from TARTAN by CMU-CS-C with TLnet; 3 Feb 84 00:24:42-EST
Received: ID <STEELE%TARTAN@CMU-CS-C.ARPA>; Fri 3 Feb 84 00:24:30-EST
Date: Fri 3 Feb 84 00:24:28-EST
From: STEELE%TARTAN@CMU-CS-C.ARPA
Subject: 1984 LISP Conference submissions deadline moved back
To: ailist-request@SRI-AI.ARPA, prolog-request@SU-SCORE.ARPA,
franz-friends-request@UCB-VAX.ARPA, common-lisp@SU-AI.ARPA,
lisp-discussion@MIT-MC.ARPA, bts%unc@UDEL-RELAY.ARPA
Because of delays that occurred in getting out the call for papers,
the deadline for submissions to the 1984 ACM Symposium on LISP and
Functional Programming (to be held August 5-8, 1984) has been moved
back from February 6 to February 15. The date for notification of
acceptance or rejection of papers is now March 20 (was March 12).
The date for return of camera-ready copy is now May 20 (was May 15).
Please forward this message to anyone who may find it of interest.
--Thanks,
Guy L. Steele Jr.
Program Chairman, 1984 ACM S. on L. and F.P.
Tartan Laboratories Incorporated
477 Melwood Avenue
Pittsburgh, Pennsylvania 15213
(412)621-2210
-------
∂06-Feb-84 2050 @MIT-ML:Moon%SCRC-TENEX@MIT-MC Request for clarification of DECODE-UNIVERSAL-TIME
Received: from MIT-ML by SU-AI with TCP/SMTP; 6 Feb 84 20:50:27 PST
Received: from SCRC-EUPHRATES by SCRC-QUABBIN with CHAOS; Mon 6-Feb-84 23:53:04-EST
Date: Mon, 6 Feb 84 23:49 EST
From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA>
Subject: Request for clarification of DECODE-UNIVERSAL-TIME
To: Common-Lisp@SU-AI.ARPA
The Mary Poppins edition specifies that the optional time-zone argument
to ENCODE-UNIVERSAL-TIME, if specified, suppresses checking for daylight
savings time. It does not say that it does the same thing for
DECODE-UNIVERSAL-TIME, and it does not deny that. Which is right?
Currrently our implementation treats the two functions consistently,
which may be in violation of the manual.
∂22-Feb-84 1847 GSB@MIT-MC 1.0e+6 vs 1.0E+6, more food for thought
Received: from MIT-MC by SU-AI with TCP/SMTP; 22 Feb 84 18:47:26 PST
Date: 22 February 1984 21:47-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: 1.0e+6 vs 1.0E+6, more food for thought
To: kmp @ MIT-OZ
cc: common-lisp @ SU-AI, BUG-LISPM @ MIT-OZ, KBE-I-FILE @ MIT-OZ
Received: from MIT-AVATAR by MIT-OZ via Chaosnet; 22 Feb 84 17:22-EST
Date: Wednesday, 22 February 1984, 17:22-EST
From: Kent M Pitman <kmp%MIT-OZ@MIT-MC.ARPA>
In Release 4.5 on PA Lisp Machine Avatar:
It would be nice if there were an advertised switch variable
controlling whether floating point numbers printed with the
"e" in complemented case. In particular, we use the Lisp floating
point number printer to display floating point numbers in the
PL/1 component of our system and since PL/1 is, in most
implementations, case sensitive, we'd prefer in that context
to see the E in the same case as the rest of the code. Is this
reasonable or should we just use ~∧ ?
NIL had been printing floating point exponents in lower case by default,
but i changed it back to upper case because most people got confused by
long floats with the lower case "l" exponent marker embedded in the output.
(I haven't done the common-lisp printing stuff yet.) Anyone else
out there in CL land have this experience, or suggestions?
∂23-Feb-84 0939 @MIT-MC:Cassels@SCRC-TENEX 1.0e+6 vs 1.0E+6, more food for thought
Received: from MIT-MC by SU-AI with TCP/SMTP; 23 Feb 84 09:38:54 PST
Received: from SCRC-ASSABET by SCRC-STONY-BROOK with CHAOS; Thu 23-Feb-84 12:32:15-EST
Date: Thu, 23 Feb 84 12:36 EST
From: "Robert A. Cassels" <Cassels%SCRC-TENEX@MIT-MC.ARPA>
Subject: 1.0e+6 vs 1.0E+6, more food for thought
To: GSB@MIT-MC.ARPA, kmp%MIT-OZ@MIT-MC.ARPA
Cc: common-lisp@SU-AI.ARPA, BUG-LISPM%MIT-OZ@MIT-MC.ARPA,
KBE-I-FILE%MIT-OZ@MIT-MC.ARPA
In-reply-to: The message of 22 Feb 84 21:47-EST from Glenn S. Burke <GSB at MIT-MC>
Date: 22 February 1984 21:47-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Received: from MIT-AVATAR by MIT-OZ via Chaosnet; 22 Feb 84 17:22-EST
Date: Wednesday, 22 February 1984, 17:22-EST
From: Kent M Pitman <kmp%MIT-OZ@MIT-MC.ARPA>
In Release 4.5 on PA Lisp Machine Avatar:
It would be nice if there were an advertised switch variable
controlling whether floating point numbers printed with the
"e" in complemented case. In particular, we use the Lisp floating
point number printer to display floating point numbers in the
PL/1 component of our system and since PL/1 is, in most
implementations, case sensitive, we'd prefer in that context
to see the E in the same case as the rest of the code. Is this
reasonable or should we just use ~∧ ?
In release 5, I completely redid the floating-point reader and printer.
They are now "completely accurate" and more modular. So Fortran and
Pascal, which have different notions from Lisp about how formatting
should be done, use the lower-level routines. I suggest you do the same
for PL/I, so you can get the semantics exactly right (the way you want
them). You can follow pointers from SI:PRINT-FLONUM and
SI:XR-READ-FLONUM or just look in SYS: SYS2; NUMER. It should be
obvious how to use upper-case exponent marks. If you have trouble
understanding the other (myriad) options, let me know. If it'll help,
ask and I'll send you copies of the Fortran and/or Pascal floating-point
printers.
NIL had been printing floating point exponents in lower case by default,
but i changed it back to upper case because most people got confused by
long floats with the lower case "l" exponent marker embedded in the output.
(I haven't done the common-lisp printing stuff yet.) Anyone else
out there in CL land have this experience, or suggestions?
It certainly occurred to me when I was doing the Common Lisp printer
that "l" would be a loser. Since we don't have long floating-point
numbers, we'll never print them. The feeling here was that lower-case
is easier to read for "e", "d", and "s", so we left it printing
lower-case. If we ever implement longs, we'll have to reconsider.
∂23-Feb-84 1638 WVANROGGEN@DEC-MARLBORO.ARPA Re: 1.0e+6 vs 1.0E+6, more food for thought
Received: from DEC-MARLBORO by SU-AI with TCP/SMTP; 23 Feb 84 16:38:45 PST
Date: Thu 23 Feb 84 19:11:21-EST
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: 1.0e+6 vs 1.0E+6, more food for thought
To: Cassels%SCRC-TENEX@MIT-MC.ARPA
cc: GSB@MIT-MC.ARPA, kmp%MIT-OZ@MIT-MC.ARPA, common-lisp@SU-AI.ARPA,
BUG-LISPM%MIT-OZ@MIT-MC.ARPA, KBE-I-FILE%MIT-OZ@MIT-MC.ARPA,
WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from ""Robert A. Cassels" <Cassels%SCRC-TENEX@MIT-MC.ARPA>" of Thu 23 Feb 84 12:48:05-EST
Vax Lisp prints long-floats with an uppercase "L", the others lowercase.
People may be surprised by the format, but they're never confused.
---Walter
-------
∂12-Mar-84 1354 @MIT-MC:benson@SPA-NIMBUS ARRAY-DIMENSIONS
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Mar 84 13:54:37 PST
Date: Mon, 12 Mar 84 13:50 PST
From: Eric Benson <benson%SPA-NIMBUS@MIT-MC.ARPA>
Subject: ARRAY-DIMENSIONS
To: Common-Lisp@SU-AI.ARPA
Is it reasonable to assume that the list returned by ARRAY-DIMENSIONS is
modifiable? It is conceivable that an implementation could actually
keep this list in the array object, so that modifying it would have the
sort of disastrous consequences that modifying a symbol's print name
has.
∂21-Mar-84 1850 GS70@CMU-CS-A Can you dig it
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Mar 84 18:49:57 PST
Date: 21 Mar 84 2149 EST (Wednesday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Can you dig it
Today I have sent off mag tapes with the (by definition) final
manuscripts for the Common Lisp Reference Manual, First Edition,
to the typesetter. Excepting possibly last-minute corrections
by telephone to the typesetter, it's out of my hands now. The publishing
schedule nominally called for copies to be available about nine
weeks after deleivery of the tapes, but it may be that the typesetter,
printer, or binder may make up some time in that schedule.
I am very grateful to everyone who sent in comments, questions, and
corrections over the last three years. I've done a lot of editing
and coordinating, but allof you have done a lot of the thinking.
I want to apologize again for often seeming unresponsive. While
I have not always had the time to respond individually to every bug
report and typographical error, I assure you that no report has been
lost. I have them all on paper, and every one was checked twice.
Yes, I fixed the inconsistencies about SPECIAL in the declarations
chapter. Yes, I fixed the screwy example of SETF of LDB. Yes,
I fixed the "version version" typo. Thanks to the dedication of
many of you who have read through this book several times, I think
it is in very good shape, highly polished and reasonably consistent.
(The copy editor for the publisher reported that she found only very
light editing necessary, mostly to correct various grammatical confusions
I had introduced and occasional use of the wrong font.) I think
this is a book we can all be proud of.
--Guy
∂23-Mar-84 2248 GS70@CMU-CS-A Common Lisp Reference Manual
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 23 Mar 84 22:48:17 PST
Date: 24 Mar 84 0130 EST (Saturday)
From: Guy.Steele@CMU-CS-A
To: common-lisp@SU-AI
Subject: Common Lisp Reference Manual
The publisher of the Common Lisp Reference Manual is Digital Press. I
understand that they may be negotiating with manufacturers to allow
them to reprint the manual in various ways as part of their product
documentation. I am leaving the business and legal aspects of this up
to Digital Press, and referring all corporate inquiries to them. My
goal is primarily to ensure that (a) no one publishes a manual that
claims to be about Common Lisp when it doesn't satisfy the Common Lisp
specifications, and (b) to make sure that everyone involved in the
Common Lisp effort is properly credited. I certainly do not want to
block anyone from implementing or using Common Lisp, or even a subset,
superset, or side-set of Common Lisp, as long as any differences are
clearly and correctly stated in the relevant documentation, and as long
as the Common Lisp Reference Manual is recognized and credited as the
definitive document on Common Lisp. This requires a certain balance
between free permission and tight control. This is why I am letting
the publisher handle it; they almost certainly have more experience
with such things than I do.
I have asked the editor at Digital Press to arrange for complimentary
copies to be sent to everyone who has contributed substantially to the
Common Lisp effort. This will include most of the people on this
mailing list, I imagine. The set of people I have in mind is listed in
the acknowledgements of the book--seventy or eighty persons
altogether--so if you see a copy of the book and find your name in that
list, you might want to wait a bit for your complimentary copy to show
up before buying one. (Because of the large number of copies involved,
they aren't really complimentary, which is to say the publisher isn't
footing the cost: the cost of them will be paid out of the royalties.
I estimate that the royalties from the entire first print run will just
about cover these free copies. It seems only fair to me that everyone
who contributed to the language design should get a copy of the final
version!)
The nominal schedule calls for the typesetter to take about five weeks
to produce camera-ready copy from the files I sent to them on magnetic
tape. The process of printing, binding, and distribution will then take
another four to five weeks. So at this point we're talking availability
at about the end of May. This is a tight and optimistic schedule; don't
blame Digital Press if it slides. (I'm certainly not about to cast any
stones!) Unless you're an implementor wanting to order a thousand
copies to distribute with your system, please don't bother the folks at
Digital Press until then; they've got enough problems. I'll send more
information to this mailing list as the date approaches.
One last note. The book is about 400 pages of 8.5" by 11" Dover output.
Apparently the publisher and typesetter decided that this made the lines
too wide for easy reading, so they will use a 6" by 9" format. This
will make the shape of the book approximately cubical. Now, there are
26 chapters counting the index, and a Rubik's cube has 26 exterior cubies.
I'll let you individually extrapolate and fantasize from there.
--Guy
∂24-Apr-84 1200 SHEBS@UTAH-20.ARPA Stream Buffering Question
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 24 Apr 84 11:59:57 PST
Date: Tue 24 Apr 84 12:59:11-MST
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
Subject: Stream Buffering Question
To: common-lisp@SU-AI.ARPA
Excelsior says nothing about how streams are to be buffered. This
is important when building editors etc. The presence of listen and
read-char-no-hang (pp 293-294) would seem to imply that unbuffered
I/O is possible, but I couldn't find anything that could be used
to declare whether a given stream is to be buffered or not. What's
the official propaganda?
stan shebs
-------
∂24-Apr-84 1820 @MIT-MC:Moon%SCRC-TENEX@SCRC-RIVERSIDE Stream Buffering Question
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Apr 84 18:17:37 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 20969; Tue 24-Apr-84 21:05:26-EST
Date: Tue, 24 Apr 84 21:04 EST
From: "David A. Moon" <Moon%SCRC-TENEX@SCRC-RIVERSIDE.ARPA>
Subject: Stream Buffering Question
To: Stan Shebs <SHEBS@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 24 Apr 84 14:59-EST from Stan Shebs <SHEBS at UTAH-20>
Date: Tue 24 Apr 84 12:59:11-MST
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
Excelsior says nothing about how streams are to be buffered. This
is important when building editors etc. The presence of listen and
read-char-no-hang (pp 293-294) would seem to imply that unbuffered
I/O is possible, but I couldn't find anything that could be used
to declare whether a given stream is to be buffered or not. What's
the official propaganda?
I believe the official propaganda is that Common Lisp does not provide
I/O facilities for building editors. In order to read control characters
one at a time from the keyboard, you have to go outside of Common Lisp
and do something implementation-dependent. You have to do the same in
order to maintain a display on a screen. These operations seem like
good candidates for standardization in a future second revision of Common
Lisp, but obviously there are a lot more implementation issues and choices
surrounding them than with CAR or REPLACE.
Incidentally, the Excelsior edition of the manual was superseded five
months ago by the Mary Poppins edition of the manual. I believe the
First edition is supposed to be in the bookstores "soon", like in six
weeks, but I don't know whether my information is accurate.
∂24-Apr-84 1852 FAHLMAN@CMU-CS-C.ARPA Stream Buffering Question
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Apr 84 18:52:45 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 24 Apr 84 21:54:30-EST
Date: Tue, 24 Apr 1984 21:54 EST
Sender: FAHLMAN@CMU-CS-C.ARPA
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Stan Shebs <SHEBS@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Stream Buffering Question
In-reply-to: Msg of 24 Apr 1984 21:04-EST from "David A. Moon" <Moon%SCRC-TENEX at SCRC-RIVERSIDE.ARPA>
I agree with Dave Moon: stream buffering, either on the input or output
side, is outside the scope of the current Common Lisp definition. The
only hooks into buffering are FORCE-OUTPUT and related functions that
give the user some control over output buffering if any buffering is in
fact being done.
-- Scott
∂04-May-84 1140 wile@ISI-VAXA I'd like on mailing list
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 4 May 84 11:40:24 PDT
Date: Friday, 4 May 1984 11:35-PDT
TO: common-lisp at SU-AI
FROM: Wile at ISI-VAXA
SUBJECT: I'd like on mailing list
SENT: Friday, 5/4/84 at 10:33:50 PST
I would like on this mailing list. I hope this message is not
automatically distributed to everyone on the list! We are developing a
Common Lisp "framework" here and would like to track all Common Lisp
developments.
Thanks.
David S. Wile
Information Sciences Institute
WILE@ISI
∂04-May-84 1742 @MIT-MC:Moon%SCRC-TENEX@SCRC-RIVERSIDE question about REQUIRE
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 May 84 17:41:50 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 50396; Fri 4-May-84 20:40:34-EDT
Date: Fri, 4 May 84 20:41 EDT
From: "David A. Moon" <Moon%SCRC-TENEX@SCRC-RIVERSIDE.ARPA>
Subject: question about REQUIRE
To: AS%hp-labs.csnet@CSNET-RELAY.ARPA
Cc: Common-Lisp@SU-AI.ARPA, AS@CSNET-RELAY.ARPA
In-reply-to: <8405031507.AA17342@HP-VENUS>
Date: 3 May 1984 0806-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Does REQUIRE get evaluated by default by the compiler? The Common Lisp manual
does not say that it does, but I find it difficult to understand how the
package system example could work otherwise. I would appreciate any
clarification you could make. Thank you.
I'm not sure why you're asking me, but I agree that it would be senseless for
the compiler of files not to evaluate at compile time any REQUIRE form that
it comes across at top level. That's what our implementation does.
∂08-May-84 1456 WVANROGGEN@DEC-MARLBORO.ARPA REQUIRE
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 8 May 84 14:56:06 PDT
Date: Tue 8 May 84 17:57:04-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: REQUIRE
To: AS%hp-labs.csnet@CSNET-RELAY.ARPA
cc: common-lisp@SU-AI.ARPA
The Vax version of Common Lisp also evaluates a REQUIRE form seen at
top-level when compiling, but the action taken is different from
(EVAL-WHEN (COMPILE) (REQUIRE ...)), since REQUIRE will try to do
COMPILE-FILE's (with :OUTPUT-FILE NIL) on the files constituting
the module if it isn't already on the provided list. There's a
similar list for modules already compiled (but not loaded). The
reasoning is that one wants to avoid altering the lisp environment,
since the normal use is to get macro definitions and special
proclamations for the compiler. If one really needs functions defined
in the lisp, the required functions will need EVAL-WHENs around
them, or you can put the EVAL-WHEN around the REQUIRE.
---Walter
-------
∂01-Jun-84 0527 DLW@SCRC-STONY-BROOK.ARPA Meeting at the ACM Symposium
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 1 Jun 84 05:26:29 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 42545; Fri 1-Jun-84 00:37:37-EDT
Date: Fri, 1 Jun 84 00:37 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: Meeting at the ACM Symposium
To: common-lisp@SU-AI.ARPA
Message-ID: <840601003736.3.DLW@CHICOPEE.SCRC.Symbolics>
Many of the Common Lisp designers and implementors will be present at
the ACM Symposium on Lisp and Functional Programming in Austin this
August. I propose a short meeting of any of us on this list, on Tuesday
August 7 at 6:15 (during the "break before banquet"). The main agenda
item (there's only time for one item, anyway) is what to do about
ambiguities or inclarities that come up in the published Common Lisp
definition: how do we keep all the implementations compatible? I don't
know where this meeting will occur (I don't know anything about the
local arrangements), but I presume we'll find something acceptable.
∂02-Jun-84 1857 masinter.pa@Xerox.ARPA ANSI Lisp
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Jun 84 18:57:14 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 02 JUN 84 18:57:06 PDT
From: masinter.pa@XEROX.ARPA
Date: 2 Jun 84 18:55:30 PDT
Subject: ANSI Lisp
To: common-lisp@SU-AI.ARPA
I've just heard an odd rumor about an ANSI Lisp group. Anybody know anything about it?
The folks at ANSI, by the way, claim not to know anything about it at all.
∂04-Jun-84 0747 WVANROGGEN@DEC-MARLBORO.ARPA macroexpansion environments
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 4 Jun 84 07:47:40 PDT
Date: Mon 4 Jun 84 10:47:30-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: macroexpansion environments
To: common-lisp@SU-AI.ARPA
Here's an interesting problem with Common Lisp:
(defvar x 1)
(defmacro m ()
(print x)
`(list ,x x))
(let ((x 2)) (m)) ;case A
(let ((x 2)) () (m)) ;case B
In case A it will print a 1 and return the list (1 2).
In case B it will print a 2 and return the list (2 2).
The problem is that special forms such as LET have to expand at least the
first form of the body in order to find out if it returns a declaration.
(More may have to be expanded if it does expand into a declaration.)
The question is what environment does the macro call get expanded in.
You'd expect that they'd have to be expanded inside the bindings set up
by the LET itself, but this isn't possible if the macro returns a
declaration, which might affect the binding. In the example above, all
instances of X are special, but that needn't have been the case. What's
disconcerting is that the results are different for the seemingly
identical cases.
Now since one isn't supposed to depend on when macros get evaluated,
nor how often they get evaluated, it might be possible ignore the
problem of having different side effects, and one could implement
the special forms to re-expand the macro if it didn't expand into a
declaration and the environment has changed. That might "resolve"
the issues for the example above, but I'm still concerned.
For example:
(setq y 1)
(defmacro decl () `(declare (special y)))
(defmacro m () (print y) `(list ,y y)))
(let ((y 2)) (decl) (m))
I don't think it would be reasonable to disallow macros expanding into
declarations. Ideas?
---Walter
-------
∂04-Jun-84 1238 Moon@SCRC-STONY-BROOK.ARPA macroexpansion environments
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 4 Jun 84 12:38:41 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 43975; Mon 4-Jun-84 15:38:52-EDT
Date: Mon, 4 Jun 84 15:38 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: macroexpansion environments
To: Walter van Roggen <WVANROGGEN@DEC-MARLBORO.ARPA>
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 4 Jun 84 10:47-EDT from Walter van Roggen <WVANROGGEN at DEC-MARLBORO>
Message-ID: <840604153807.3.MOON@EUPHRATES.SCRC.Symbolics>
Date: Mon 4 Jun 84 10:47:30-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Here's an interesting problem with Common Lisp:
(defvar x 1)
(defmacro m ()
(print x)
`(list ,x x))
(let ((x 2)) (m)) ;case A
(let ((x 2)) () (m)) ;case B
In case A it will print a 1 and return the list (1 2).
In case B it will print a 2 and return the list (2 2).
Think about what will happen when you compile this code. Both cases will
print a 1 AT COMPILE TIME and include the list (1 2) in the expanded code.
Or, if you don't put an eval-when compile around the defvar of x, it will
blow out at compile time.
I don't think this is a very interesting problem: you have simply
constructed a program whose semantics cannot possibly be well-defined.
∂05-Jun-84 0402 DLW@SCRC-STONY-BROOK.ARPA Kyoto Common Lisp
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 5 Jun 84 04:01:51 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 44212; Tue 5-Jun-84 00:27:34-EDT
Date: Tue, 5 Jun 84 00:26 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: Kyoto Common Lisp
To: common-lisp@SU-AI.ARPA
Message-ID: <840605002611.2.DLW@CHICOPEE.SCRC.Symbolics>
Presumably many of you got the same letter as I did, from Dr. Yuasa of
Kyoto University, about Kyoto Common Lisp for the Data General Eclipse
MV under AOS/VS. Does anybody know more about this than the letter
says? I will be at Kyoto University on July 11, and perhaps I will be
able to learn more then.
∂05-Jun-84 0621 WVANROGGEN@DEC-MARLBORO.ARPA Re: macroexpansion environments
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 5 Jun 84 06:19:20 PDT
Date: Tue 5 Jun 84 09:19:09-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: macroexpansion environments
To: Moon@SCRC-RIVERSIDE.ARPA
cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from ""David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>" of Mon 4 Jun 84 15:45:39-EDT
What the examples do when compiled isn't the point. They needn't even
print anything at compile time (and also needn't cause an error).
I agree that the examples constitute programs whose semantics aren't
well-defined. What bothers me is how innocuously similar the two
cases are and that macros expanding into declarations ought to work
"like you'd expect", but don't and can't.
---Walter
-------
∂05-Jun-84 0710 FAHLMAN@CMU-CS-C.ARPA Kyoto Common Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Jun 84 07:07:19 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 5 Jun 84 10:06:06-EDT
Date: Tue, 5 Jun 1984 10:06 EDT
Sender: FAHLMAN@CMU-CS-C.ARPA
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Kyoto Common Lisp
In-reply-to: Msg of 5 Jun 1984 00:26-EDT from "Daniel L. Weinreb" <DLW at SCRC-RIVERSIDE.ARPA>
A group within Data General is using our Common Lisp sources for a
project that I'm not allowed to describe, but whose general goals are
probably not hard to guess. They passed our code (a rather old version,
I'm afraid) along to Nippon Data General, who collaborated with the
Kyoto people to bring up a quick implementation on the Eclipse MV. My
source at DG tells me that this is a rather thorough implementation, but
rather slow as well -- the point was to get an implementation up, not to
produce a production-quality system. As the note from Kyoto says, they
use C as the compiler back-end. That's all I know, and since we have no
Eclipses around here, we have no way of taking a closer look. I will be
interested in hearing what Weinreb can learn first-hand when he's over
there.
-- Scott
∂09-Jun-84 1123 @MIT-ML:DLW@SCRC-TENEX Manuals
Received: from MIT-ML.ARPA by SU-AI.ARPA with TCP; 9 Jun 84 11:23:14 PDT
Date: 8 Jun 1984 2210-EDT
From: Daniel L. Weinreb <DLW%SCRC-TENEX@MIT-ML>
Subject: Manuals
To: common-lisp@SU-AI
A carton of Common Lisp manuals arrived at Symbolics today, from Digital
Press. We were all very happy to see them! It looks like we turned
Common Lisp from an initial conception to a final published standards
document (Release 1.0) in under three years, which I think is something
we can all be proud of. Congratulations to everybody, esspecially
Guy Steele!
-------
∂09-Jun-84 1312 SHEBS@UTAH-20.ARPA Leakiness and Kernels
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 9 Jun 84 13:12:08 PDT
Date: Sat 9 Jun 84 11:11:10-MDT
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
Subject: Leakiness and Kernels
To: common-lisp@SU-AI.ARPA
(Thanx for the replies to my question about io buffering)
As far as I can tell, the CL spec does not say anything about how much
an implementation is allowed to "leak", that is, how much and what sort
of space does not have to be reclaimed within a running Lisp process.
Seems like an implementation-dependent thing, but then one has to worry
about whether a 3-hour running time program that does 1K or more GCs
will be able to run on different machines. I suppose stack depths and
so forth are also portability barriers of the same sort. What's the
story?
Also, I've heard much discussion around at Utah about how a CL kernel
must be gigantic, and that Hedrick@Rutgers had done a kernel that
took up an entire segment on the 20, and so forth. Is there some
deep reason why this must be true? Much of CL can be (inefficiently)
implemented as macros, and even some of the datatypes could be
done as structures defined by loadable modules. Exactly what *must*
be in the kernel?
stan shebs
-------
∂09-Jun-84 1437 HEDRICK@RUTGERS.ARPA Re: Leakiness and Kernels
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 9 Jun 84 14:37:26 PDT
Date: 9 Jun 84 17:36:14 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Leakiness and Kernels
To: SHEBS@UTAH-20.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Stan Shebs <SHEBS@UTAH-20.ARPA>" of 9 Jun 84 13:11:10 EDT
It is certainly true that Common Lisp is more complex than the Lisps
I know and love. But it's not *that* big. Our current kernel is
40312 words (79 pages). The whole thing takes 559 pages, which is
somewhat more than a section. But that's not the kernel: that's
the whole implementation. And we don't have a compiler yet, so
that is interpreted code. I assume the compiled version will be
smaller. Note that our "kernel" is in fact somewhat larger than
necessary. I have handcoded everything that I thought would
improve performance. This includes EVAL, most of READ and PRINT,
and various other things. There are also complications such as
an EMACS interface, and code to save a core image without using
the SSAVE JSYS. These are not part of the Common Lisp definition.
(And in fact the save code is no longer needed, as SSAVE now works
with multi-section programs.)
If you wanted to do an implementation on a microcomputer, using a
minimal kernel, I don't think the kernel for Common Lisp would be
any bigger than the kernel for any other modern dialect. The
things I object to most are complexities in lambda binding, multiple
values, and the way the sequence functions are designed. But only
multiple values are really needed in the kernel, and the amount of
code for them is minimal.
-------
∂09-Jun-84 1558 FAHLMAN@CMU-CS-C.ARPA Leakiness and Kernels
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 9 Jun 84 15:57:50 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 9 Jun 84 18:57:09-EDT
Date: Sat, 9 Jun 1984 18:57 EDT
Sender: FAHLMAN@CMU-CS-C.ARPA
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: Stan Shebs <SHEBS@UTAH-20.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Leakiness and Kernels
In-reply-to: Msg of Sat 9 Jun 84 11:11:10-MDT from Stan Shebs <SHEBS at UTAH-20.ARPA>
The Perq implemenation of Common Lisp weighs in at 2.5 megabytes as it
sits out there on the disk. That includes the Compiler, the Hemlcok
text editor, debugging aids, documentation strings, and all of Common
Lisp. For just the language itself, and flushing the doc strings, I
think we'd come in at a megabyte or maybe somewhat less, but of course
you would not want to use such a system.
There's a lot of stuff in Common Lisp that doesn't have to be there --
hyperbolic arctan, Roman numeral output in Format, etc. We put that
stuff in because most of the designers felt that, starting now, any
machine without virtual memory is not interesting for serious work.
Given that people were going to add these things anyway, we figured that
they may as well be built in so that they are done in a standard way.
Of course, the last generation of microcomputer chips (and the current
generation of low-end personal computers) does not support virtual memory.
Any Common Lisps on them will have to either go for a subset or get very
clever about overlays and such. But this is a temporary phase that
won't be with us for long, and it seemed a shame to ruin the language in
order to accommodate these transitional machines.
Storage-management is completely up to the implementation, but in my
opinion any implementation that leaks storage at all is broken. A
Xerox-style reference-count GC is OK as long as it is backed up with a
real garbage collector, but not otherwise. Most Common Lisp
implementations will use some sort of copying GC, since strings and
other ragged-length data structures are so important in this language.
In GC's of this sort, there is no reason for any leaking -- it's easy
enough to do it right.
-- Scott
∂13-Jun-84 0953 DLW@SCRC-STONY-BROOK.ARPA Re: Leakiness and Kernels
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jun 84 09:53:19 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 46522; Mon 11-Jun-84 07:15:50-EDT
Date: Mon, 11 Jun 84 07:14 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: Re: Leakiness and Kernels
To: HEDRICK@RUTGERS.ARPA, SHEBS@UTAH-20.ARPA
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 9 Jun 84 17:36-EDT from Charles Hedrick <HEDRICK at RUTGERS>
Message-ID: <840611071410.4.DLW@CHICOPEE.SCRC.Symbolics>
Gold Hill Computers in Cambridge hopes to do a Common Lisp for the IBM/PC.
You could talk to them.
∂14-Jun-84 2039 FAHLMAN@CMU-CS-C.ARPA Last-minute change
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Jun 84 20:39:27 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 14 Jun 84 23:38:08-EDT
Date: Thu, 14 Jun 1984 23:38 EDT
Sender: FAHLMAN@CMU-CS-C.ARPA
From: Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Last-minute change
Before Flag Day ends at midnight, there's one little change I'd like to
get into Defsetf.... Oh, never mind.
∂15-Jun-84 2208 HEDRICK@RUTGERS.ARPA request for list of changes
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 15 Jun 84 22:08:05 PDT
Date: 16 Jun 84 01:08:52 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: request for list of changes
To: common-lisp@SU-AI.ARPA
Does anyone have a list of substantive changes between Mary Poppins
and the published manual? I am thinking of actual differences in
the language, not just editorial improvements. I just got my copy
of the printed manual. My first use of it was debugging the
handling of syntax classes in our READ. The main bug was that we
had not implemented an illegal character type. Much to my surprise,
there is now an illegal syntax class, as well as an illegal attribute
for constituents. Let's hope I was just unlucky that the first thing
I looked up had changed. I don't really want to reimplement the
language, nor to check the manual line by line.
-------
∂20-Jun-84 2152 GS70@CMU-CS-A.ARPA "ANSI Lisp" rumor
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 20 Jun 84 21:52:02 PDT
Date: 21 Jun 84 0050 EDT (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: masinter.pa@XEROX.ARPA
Subject: "ANSI Lisp" rumor
CC: common-lisp@SU-AI.ARPA
In-Reply-To: "masinter.pa@XEROX.ARPA's message of 2 Jun 84 20:55-EST"
I do not know of any official effort within ANSI to do anything at all
about LISP. Here is what I do know: I have been told that a group
in China has suggested that perhaps an ISO standard for LISP should
be promulgated. I know nothing more about it than that. However,
at the request of David Wise and J.A.N. Lee, I have sent a copy of
the Common LISP Manual to J.A.N. Lee, who has been involved with
standards of various kinds at ACM. (David Wise is a member of the SIGPLAN
council, or whatever it is called, and is the LISP expert within that
body.) The idea is that if either an ISO or ANSI standards effort
were to be undertaken, Wise and Lee feel that such an effort should
certainly take the work done on Common LISP into account, and they want
people in the standards organizations to be aware of the Common LISP
work. I sent a copy of the Table of Contents to Lee several months
ago, and it was my understanding that he might choose to circulate
copies of it to, for example, members of the SIGPLAN council.
That's where it stands. I repeat, I know of no effort actually to
start a standards effort; Wise and Lee merely want certain people to
be prepared by already having information about Common LISP if any of
a number of possible developments should unfold.
--Guy
∂22-Jun-84 1342 HEDRICK@RUTGERS.ARPA request for information about implementations
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 22 Jun 84 13:42:19 PDT
Date: 22 Jun 84 16:41:38 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: request for information about implementations
To: common-lisp@SU-AI.ARPA
One of our users is interested in finding implementations of Common Lisp
for
IBM 3083 under VM/CMS and/or UNIX (alias UTS),
68000 under Unix
Implementations for other Unix systems that could reasonably be ported
would also be interesting to them.
They would also like to have access to a compiler that they could look
at, and preferably use as the basis for their own compiler.
-------
∂24-Jun-84 2014 HEDRICK@RUTGERS.ARPA [HAUTIN@RUTGERS.ARPA: common lisp]
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 24 Jun 84 20:14:12 PDT
Date: 24 Jun 84 23:13:51 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: [HAUTIN@RUTGERS.ARPA: common lisp]
To: common-lisp@SU-AI.ARPA
I decided you might be interested in the full text of the request that I
alluded to before.
In case any of your are curious, the answer to the first question is
that Tops-20 Common Lisp runs. It is fairly complete. However currently
there is no compiler. It should be finished by late fall. It will
probably compile the full language by the end of the summer, but without
doing the sorts of optimizations one would like. The Tops-20
implementation is based on CMU's Spice Lisp, as is DEC's VAX
implementation. At the moment it looks like we will support it from
here. We are a bit uncertain what sort of demand there is for a new
DEC-20 language at this late date. If a significant number of customers
want (and will pay for) real support, we and DEC would be happy to
arrange that. We just don't know whether there will be sufficient
demand for this to set up a real support organization. DEC-20 Lisp is
not based on the VAX sources. However we are looking at what the VAX
implementors have done, and will try to supply a reasonable degree of
compatibility in the language.
---------------
Mail-From: HAUTIN created at 22-Jun-84 09:32:06
Date: 22 Jun 84 09:32:06 EDT
From: HAUTIN@RUTGERS.ARPA
Subject: common lisp
To: hedrick@RUTGERS.ARPA
cc: hautin@RUTGERS.ARPA
Original-language: French
Translated-by: hedrick@RUTGERS.ARPA
Hello,
I would like to ask some questions about Common Lisp.
1) How is your project going?
Does your compiler work yet?
Will there be DEC support? (DEC keeps pushing back availability
for VAX Common Lisp.)
2) What will be the impact of Common Lisp on other American research
groups, for example Yale, Berkeley, Xerox, and BBN?
3) We here at CNET would like to standardize on a Lisp for
VAX 11/780
IBM 3083 with VM/CMS and/or UNIX/UTS
SM90 UNIX/68000 (This is a multi-processor machine
developed by CNET)
4) At the moment we use NIL from MIT on the VAX. We are generally quite
pleased with it.
For IBM we don't have anything
For the SM90 we have LELISP from INRIA, but it has a few problems
(separate compilation, an enviornment that is not as good as
NIL's)
5) Would it be possible to get a Common Lisp compiler that we could port
to these machines? or if not, at least a compiler that we could look at
that is based on the Common Lisp specification?
I would be very grateful if you could help us with these various problems.
Do you know of a bboard about Smalltalk? At the University of Brest a
group has implemented Smalltalk for our SM90 system. They would be
quite interested in comparing their implementation with others. Their
implementation currently works. They are now working on performance
improvements.
Thank you,
F Hautin
-------
-------
∂30-Jun-84 1524 SHEBS@UTAH-20.ARPA Pathname Questions
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 30 Jun 84 15:24:02 PDT
Date: Sat 30 Jun 84 16:24:43-MDT
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
Subject: Pathname Questions
To: common-lisp@SU-AI.ARPA
(Pardon this if it's been fixed since Excelsior, we don't have anything
more recent here)
Excelsior defines the pathname merging operation as taking a pathname,
a defaults pathname, default type, and default version, while the
merge-pathnames function does not take a default type as an option.
Is this a mistake? If not, then how does one specify a default type
for merging?
Also, *load-pathname-defaults* is supposedly only a single pathname,
however, it's very convenient to have a list of pathnames to search.
This is very handy in PSL for loading modules, since you can search
your own directory, the directory of new hacks, and the standard
load module directory, in that order. Does the CL spec preclude using
a list of pathnames in *load-pathname-defaults*?
adTHANXvance,
stan shebs
-------
∂02-Jul-84 1526 AS%hp-hulk.csnet@csnet-relay.arpa &REST in DEFMACRO
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 2 Jul 84 15:26:20 PDT
Received: From hp-labs.csnet by csnet-relay; 2 Jul 84 18:11 EDT
Received: by HP-VENUS id AA00732; Mon, 2 Jul 84 10:04:53 pdt
Message-Id: <8407021704.AA00732@HP-VENUS>
Date: 2 Jul 1984 0942-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Subject: &REST in DEFMACRO
To: common-lisp@su-ai.arpa
Cc: AS@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
The book says that a lambda-list may appear in place of a parameter
name in DEFMACRO. Was this meant to apply to a &REST parameter
as well? This seems like a bad idea. For example:
(defmacro foo (&optional a b &rest (c d)) ...)
Does this mean that a, b, c, and d are all required?
Or is &rest (c d) ==> &optional c d?
Please tell me that it is illegal!
-------
∂06-Jul-84 1746 AS%hp-hulk.csnet@csnet-relay.arpa Query about IN-PACKAGE
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 6 Jul 84 17:45:59 PDT
Received: From hp-labs.csnet by csnet-relay; 6 Jul 84 20:18 EDT
Received: by HP-VENUS id AA00673; Fri, 6 Jul 84 16:49:20 pdt
Message-Id: <8407062349.AA00673@HP-VENUS>
Date: 6 Jul 1984 1649-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Subject: Query about IN-PACKAGE
To: Common-Lisp@su-ai.arpa
Cc: AS@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
If the statement (IN-PACKAGE "FOO") is executed in a context where the package
"FOO" exists but does not USE the "LISP" package, should the "LISP" package be
added to the use-list of the package "FOO"? A literal reading of the CL book
says YES. My intuition says NO. I had assumed that using IN-PACKAGE with one
argument is the recommended way to "enter" a package, but such usage assumes
no side-effects on the package itself. Am I misinterpreting the intent of
the definition?
-------
∂06-Jul-84 2013 FAHLMAN@CMU-CS-C.ARPA Query about IN-PACKAGE
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 6 Jul 84 20:13:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 6 Jul 84 23:13:25-EDT
Date: Fri, 6 Jul 1984 23:13 EDT
Message-ID: <FAHLMAN.12029299069.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: AS%hp-labs.csnet@CSNET-RELAY.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Query about IN-PACKAGE
In-reply-to: Msg of 6 Jul 1984 19:49-EDT from AS%hp-labs.csnet at csnet-relay.arpa
The intent was that if package "FOO" already exists, (IN-PACKAGE "FOO")
would make it the current package but would not alter the USE list.
However, if a :USE argument is present, any new packages it contains
would be merged in.
Until you brought it up, it hadn't occurred to me that this might be
read as requiring the LISP package to be used if there is no explicit
:USE argument -- something to clarify in the second edition.
-- Scott
∂06-Jul-84 2301 GS70@CMU-CS-A.ARPA Re: &REST in DEFMACRO
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 6 Jul 84 23:01:42 PDT
Date: 7 Jul 84 0152 EDT (Saturday)
From: Guy.Steele@CMU-CS-A.ARPA
To: AS%hp-labs.csnet@csnet-relay.arpa
Subject: Re: &REST in DEFMACRO
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <8407021704.AA00732@HP-VENUS>
Well, this is what I would call a "curprising consequence",
but yes, I would say that
(defmacro foo (&optional a b &rest (c d)) ...)
in effect makes a, b, c, and d all be required, else the parameters
c and d could never be satisfied. You can get the effect you seem
to want by writing
(defmacro foo (&optional a b &rest (&optional c d) ...) ...
--Guy
∂06-Jul-84 2317 GS70@CMU-CS-A.ARPA Re: Query about IN-PACKAGE
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 6 Jul 84 23:17:09 PDT
Date: 7 Jul 84 0202 EDT (Saturday)
From: Guy.Steele@CMU-CS-A.ARPA
To: AS%hp-labs.csnet@csnet-relay.arpa
Subject: Re: Query about IN-PACKAGE
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <8407062349.AA00673@HP-VENUS>
I am having trouble finding what parts of the manual answer your
question "YES". Could you cite specific passages, with page numbers,
so I can study the question more carefully?
--Guy
∂10-Jul-84 1006 AS%hp-hulk.csnet@csnet-relay.arpa Re: Query about IN-PACKAGE
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 10 Jul 84 10:04:27 PDT
Received: From hp-labs.csnet by csnet-relay; 10 Jul 84 12:53 EDT
Received: by HP-VENUS id AA29000; Mon, 9 Jul 84 09:55:49 pdt
Message-Id: <8407091655.AA29000@HP-VENUS>
Date: 9 Jul 1984 0955-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Subject: Re: Query about IN-PACKAGE
To: Guy.Steele%cmu-cs-a.arpa@csnet-relay.arpa
Cc: AS@csnet-relay.arpa, Common-Lisp@su-ai.arpa
In-Reply-To: Your message of 6-Jul-84
Source-Info: From (or Sender) name not authenticated.
On second reading, I would no longer claim what I said in my previous message,
although the text (pg. 183) probably should make it clearer that the :USE
parameter to IN-PACKAGE defaults to '("LISP") ONLY if the package does not
already exist, and otherwise defaults to NIL. The source of the confusion is
the (conditional) statement that IN-PACKAGE is similar to MAKE-PACKAGE, which
states that "if not supplied, :USE defaults to a list of one package, the LISP
package".
-------
∂11-Jul-84 1926 Moon@SCRC-STONY-BROOK.ARPA Pathname Questions
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 11 Jul 84 19:26:27 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60121; Wed 11-Jul-84 22:28:25-EDT
Date: Wed, 11 Jul 84 22:25 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Pathname Questions
To: Stan Shebs <SHEBS@UTAH-20.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 30 Jun 84 18:24-EDT from Stan Shebs <SHEBS at UTAH-20>
Message-ID: <840711222507.6.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sat 30 Jun 84 16:24:43-MDT
From: Stan Shebs <SHEBS@UTAH-20.ARPA>
(Pardon this if it's been fixed since Excelsior, we don't have anything
more recent here)
You should go out to your nearest bookstore (that carries Digital Press books)
and buy a few copies before they run out.
Excelsior defines the pathname merging operation as taking a pathname,
a defaults pathname, default type, and default version, while the
merge-pathnames function does not take a default type as an option.
Is this a mistake? If not, then how does one specify a default type
for merging?
These sound like typos; no doubt they're fixed in newer versions.
Also, *load-pathname-defaults* is supposedly only a single pathname,
however, it's very convenient to have a list of pathnames to search.
This is very handy in PSL for loading modules, since you can search
your own directory, the directory of new hacks, and the standard
load module directory, in that order. Does the CL spec preclude using
a list of pathnames in *load-pathname-defaults*?
See the documentation of REQUIRE. LOAD is an operation on single files.
∂13-Jul-84 1423 AS%hp-hulk.csnet@csnet-relay.arpa extended tokens?
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 14:23:43 PDT
Received: From hp-labs.csnet by csnet-relay; 13 Jul 84 17:19 EDT
Received: by HP-VENUS id AA08670; Fri, 13 Jul 84 11:17:35 pdt
Message-Id: <8407131817.AA08670@HP-VENUS>
Date: 13 Jul 1984 1118-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Subject: extended tokens?
To: Common-Lisp@su-ai.arpa
Cc: AS@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Section 22.1 sometimes talks about "extended tokens" which are presumably
different than "tokens", but I do not see any explanation of what the
difference is. Is a concept of "extended tokens" meaningful and useful or is
this an artifact?
-------
∂13-Jul-84 1425 AS%hp-hulk.csnet@csnet-relay.arpa the meaning of #,
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 14:25:26 PDT
Received: From hp-labs.csnet by csnet-relay; 13 Jul 84 17:21 EDT
Received: by HP-VENUS id AA10552; Fri, 13 Jul 84 13:20:11 pdt
Message-Id: <8407132020.AA10552@HP-VENUS>
Date: 13 Jul 1984 1320-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
Subject: the meaning of #,
To: COMMON-LISP@su-ai.arpa
Cc: AS@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
I am having a lot of trouble understanding the intended meaning of "#," in
compiled code. I find it hard to believe that it is really intended to be
like "#.", as the manual implies. In particular, the result of "#." in a form
becomes PART OF the form. Thus, for example, you can do (DEFMACRO FOO
#.(MUMBLE) ...) and the result of invoking MUMBLE is used as the parameter
list to DEFMACRO. Similarly, if I say (SETQ X #.(MUMBLE)) and MUMBLE returns
a list, then the list will be evaluated. Is the intent that "#," can be used
this way (in compiled code), or can it be used only within quoted structures?
Implementors: How have you implemented "#,"? Are there are restrictions on its
use? If so, can they be stated clearly?
Thank you.
-------
∂13-Jul-84 1925 Moon@SCRC-STONY-BROOK.ARPA the meaning of #,
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Jul 84 19:25:42 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 60666; Fri 13-Jul-84 22:26:49-EDT
Date: Fri, 13 Jul 84 22:26 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: the meaning of #,
To: AS%hp-labs.csnet@CSNET-RELAY.ARPA
Cc: COMMON-LISP@SU-AI.ARPA, AS@CSNET-RELAY.ARPA
In-reply-to: <8407132020.AA10552@HP-VENUS>
Date: 13 Jul 1984 1320-PDT
From: AS%hp-labs.csnet@csnet-relay.arpa
I am having a lot of trouble understanding the intended meaning of "#," in
compiled code. I find it hard to believe that it is really intended to be
like "#.", as the manual implies. In particular, the result of "#." in a form
becomes PART OF the form. Thus, for example, you can do (DEFMACRO FOO
#.(MUMBLE) ...) and the result of invoking MUMBLE is used as the parameter
list to DEFMACRO. Similarly, if I say (SETQ X #.(MUMBLE)) and MUMBLE returns
a list, then the list will be evaluated. Is the intent that "#," can be used
this way (in compiled code), or can it be used only within quoted structures?
Implementors: How have you implemented "#,"? Are there are restrictions on its
use? If so, can they be stated clearly?
This feature was taken from the Lisp Machine. The intention is that #, can only
be used in constants, not in forms. For example, compiling a file containing
the form (DEFUN FOO () #,BAR) gives an error. (DEFUN FOO () '#,BAR) works.
Anything that the compiler actually has to process at compile time cannot be
a #, since such objects do not exist until load time.
I see what you mean about having a lot of trouble understanding it: the
writeup on #, in the Common Lisp manual is even worse than the writeup
on it in the Lisp Machine Manual.
∂15-Jul-84 0855 WVANROGGEN@DEC-MARLBORO.ARPA #,
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 15 Jul 84 08:55:39 PDT
Date: Sun 15 Jul 84 11:54:24-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: #,
To: common-lisp@SU-AI.ARPA
"The intention is that #, can only be used in constants, not in forms."
This seems unnecessarily restrictive. #, should act like a load-time
constant. It can be used wherever a form would normally be evaluated.
The form has to be evaluated at top-level.
(DEFUN FOO (X)
`(,X #,(PRINT "This prints at load time.") NON-EVALUATED))
(DEFUN BAR (X)
(LIST X #,(PRINT "This too.") 'EVALUATED))
When loading these functions, it prints the messages, and then
(FOO 3) ==> (3 "This prints at load time." NON-EVALUATED)
(BAR 3) ==> (3 "This too." EVALUATED)
The loader evaluates the form and stuffs the value as a constant in
the compiled function object.
---Walter
-------
∂15-Jul-84 0952 FAHLMAN@CMU-CS-C.ARPA #,
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Jul 84 09:51:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 15 Jul 84 12:50:23-EDT
Date: Sun, 15 Jul 1984 12:50 EDT
Message-ID: <FAHLMAN.12031544946.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Walter van Roggen <WVANROGGEN@DEC-MARLBORO.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: #,
In-reply-to: Msg of 15 Jul 1984 11:54-EDT from Walter van Roggen <WVANROGGEN at DEC-MARLBORO.ARPA>
Moon's proposal for #, and van Roggen's are both equally restricitve, I
think. The question is simply one of whether the user is required to
quote the expression containing the #, or whether #, quotes itself
implicitly. It seems to me that Moon's proposal wins on three counts:
1. Under Moon's scheme, #, could be used in any context that wants a
constant, not just within a (QUOTE ...) form. If #, supplies an
implicit quote, that leads to double quoting if you use it in
already-quoted contexts.
2. As Moon says, this is already in use in Zetalisp, so we may as well
remain compatible with their convention.
3. If #, were to supply an implicit quote, it would no longer be
analogous to #. Bugs and confusion would result.
-- Scott
∂16-Jul-84 2056 GS70@CMU-CS-A.ARPA Forwarded mail
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Jul 84 20:55:51 PDT
Date: 16 Jul 84 2355 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Forwarded mail
- - - - Begin forwarded message - - - -
Return-Path:<SCHUMACHER%hp-hulk.csnet@csnet-relay.arpa>
Received: from CSNET-RELAY.ARPA by CMU-CS-A.ARPA; 10 Jul 84 13:33:56 EDT
Received: From hp-labs.csnet by csnet-relay; 10 Jul 84 12:59 EDT
Received: by HP-VENUS id AA07498; Mon, 9 Jul 84 16:03:06 pdt
Message-Id: <8407092303.AA07498@HP-VENUS>
Date: Mon 9 Jul 84 16:03:03-PDT
From: SCHUMACHER%hp-labs.csnet@csnet-relay.arpa
Subject: t, nil & the package system.
To: guy.steele%cmu-cs-a@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Guy,
What is the home package of t and nil ?? Presuming that this package
is in fact the lisp package, what happens when *package* is bound to
package foo, which doesn't have the lisp package on its use-list ?? Will
t print as lisp:t ?? Is it legal to shadow t or nil ??
-Lee
(you can respond to les@cmu-c, I have the mail forwarding set...)
-------
- - - - End forwarded message - - - -
∂16-Jul-84 2057 GS70@CMU-CS-A.ARPA Re: t, nil & the package system.
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 16 Jul 84 20:57:22 PDT
Date: 16 Jul 84 2357 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
To: SCHUMACHER%hp-labs.csnet@csnet-relay.arpa
Subject: Re: t, nil & the package system.
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <8407092303.AA07498@HP-VENUS>
I believe that t and nil, like all other symbols defined in the
Common LISP Manual, must be in the lisp package (or at least accessible
from it). It certainly is possible to shadow them, just as
one may shadow CAR or COND.
--Guy
∂17-Jul-84 0612 WVANROGGEN@DEC-MARLBORO.ARPA Re: #,
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 17 Jul 84 06:12:42 PDT
Date: Tue 17 Jul 84 09:11:23-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: #,
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Sun 15 Jul 84 12:49:24-EDT
I think you misunderstood what I thought #, does. I didn't say that
#, is self-quoting. Just as reading the number 3 isn't self-quoting,
neither does #, have to be. I believe #,form represents the object
returned by evaluating form at load time, not some expression which
may evaluate to some object at load time. The problem here is that
people have drawn the parallel with #. a bit too far. Unlike #. and
other read macros, it isn't clear what #, expands int. I think we
all agree what #, does inside data structures and that it's illegal
as the first thing in a LET, for example. Allowing a #, where one
would expect to evaluate an expression seems perfectly reasonable
if one thinks of the #, modifying when and how often the form gets
evaluate One might think of #, expanding into a form which the
compiler can treat as a reference to a variable that gets initialized
at load time.
On a related issue, what does EVAL-WHEN return, when it did evaluate
something, and when it didn't?
---Walter
-------
∂18-Jul-84 0823 RPG Drag
∂17-Jul-84 1854 FAHLMAN@CMU-CS-C.ARPA Drag
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Jul 84 18:53:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 17 Jul 84 21:53:23-EDT
Date: Tue, 17 Jul 1984 21:53 EDT
Message-ID: <FAHLMAN.12032168083.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Drag
In-reply-to: Msg of 17 Jul 1984 21:36-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
MV-CALL with an optional arg is expensive too, unless you were going to
do a call anyway. I agree with Gabriel that built-in constructs should
generally stick to a fixed number of return values, especially when the
item in question is going to appear in places that affect system
performance in an important way. The reader is certainly one of those.
Maybe this is one of those things we can fix once we have a way of
fixing things like this.
-- Scott
∂18-Jul-84 0823 RPG
∂17-Jul-84 1901 RPG Well
To: quinquevirate@SU-AI.ARPA
MV-CALL with an optional has a nice hackish ring to it, but
optionals are somewhat of a roundabout way to implement a means
to get at a piece of information that is sitting on the stack (or
in a register - the number of values returned). The MV-call with
optionals simply isn't isn't clearly computing the number of values,
and unclear code is not the CL ideal (I hope). Alas, I fear a lore
of how to hack certain operations will become part of the CL lore
in short order.
-rpg*
∂18-Jul-84 0825 RPG Drag
∂17-Jul-84 1945 Moon@SCRC-QUABBIN.ARPA Drag
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jul 84 19:44:48 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 65318; Tue 17-Jul-84 22:43:55-EDT
Date: Tue, 17 Jul 84 22:43 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Drag
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>,
Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12032168083.BABYL@CMU-CS-C.ARPA>,
The message of 17 Jul 84 22:01-EDT from Dick Gabriel <RPG at SU-AI>
Message-ID: <840717224356.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: Tue, 17 Jul 1984 21:53 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
MV-CALL with an optional arg is expensive too, unless you were going to
do a call anyway. I agree with Gabriel that built-in constructs should
generally stick to a fixed number of return values, especially when the
item in question is going to appear in places that affect system
performance in an important way. The reader is certainly one of those.
I'd like to see some evidence before I would believe that calling a function
with MULTIPLE-VALUE-CALL is slower than calling a user-defined reader macro
function, not to mention all the I/O that that function does. (Beside the
point, but I'd also like to see some evidence before I would believe that the
speed of the reader affects the performance of most systems in any important
way.)
Date: 17 Jul 84 1901 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
MV-CALL with an optional has a nice hackish ring to it, but
optionals are somewhat of a roundabout way to implement a means
to get at a piece of information that is sitting on the stack (or
in a register - the number of values returned).
Of course there are subprimitives (%multiple-value-push and %pop)
available, and used, in our implementation for accessing that
information. You can see how they necessarily have to depend on the
particular implementation of multiple-value-returning, though.
The MV-call with
optionals simply isn't isn't clearly computing the number of values,
and unclear code is not the CL ideal (I hope). Alas, I fear a lore
of how to hack certain operations will become part of the CL lore
in short order.
It seems to me that if
(multiple-value-call #'(lambda (&optional (value nil value-p)
...)
function args...)
doesn't compile as efficiently as whatever subprimitives are available
in the implementation to do the same thing one would be entirely
justified in complaining to the compiler maintainer (in fact it does not
currently compile as efficiently in our implementation).
I don't see it as very unclear, although if I was going to use it I would
hide it behind a macro (named something like call-reader-macro-function).
Certainly the symmetry between arguments and values ought to make this
construct self-evident.
I really feel uncomfortable being put in the position of defending this way
of doing reader macros, since I think it sucks. But I don't think it is fair
to react "Oh, multiple values, ugh, I can't understand those and they must
be inefficient." I don't think there is any inherent reason why they have
to be any less efficient than any alternative way of communicating the same
information.
∂18-Jul-84 0826 RPG Drag
∂18-Jul-84 0822 RPG Drag
∂17-Jul-84 1836 Moon@SCRC-QUABBIN.ARPA Drag
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Jul 84 18:36:43 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 65298; Tue 17-Jul-84 21:35:54-EDT
Date: Tue, 17 Jul 84 21:36 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Drag
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 17 Jul 84 15:53-EDT from Dick Gabriel <RPG at SU-AI>
Message-ID: <840717213604.1.MOON@EUPHRATES.SCRC.Symbolics>
Date: 17 Jul 84 1253 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
We've got a student here re-doing a CL reader, and we were looking at the
rough sketch of the reader in the IO section. Macro-character functions
return multiple values, either 0 or 1 of them. If no values are returned, then
the reader continues as if nothing happened, and if 1 value is returned, then
that is the value of the read operation.
Although this is a nice way to set things up for the user who is writing
read macros, it's slightly not so nice for the implementation. The
only way to test for 0 or 1 values is to cons up a list of the values and
examine that list. For non-microcoded machines, this is an extra cons
that would not have had to happen if the read-character function always returned
2 values, a real value and a flag stating that the value is to be ignored.
It is possible to do multiple values decently on stock hardware, but
not lists in the stack (cdr-coding).
Use MULTIPLE-VALUE-CALL.
∂27-Jul-84 0623 G.TI.CSL@UTEXAS-20.ARPA validation suite
Received: from UTEXAS-20.ARPA by SU-AI.ARPA with TCP; 27 Jul 84 06:23:42 PDT
Date: Fri 27 Jul 84 08:23:35-CDT
From: G.TI.CSL@UTEXAS-20.ARPA
Subject: validation suite
To: common-lisp@SU-AI.ARPA
I am looking for programs developed to VALIDATE an implementation's
conformance to the Common Lisp specification. Those with an aura of
OFFICIALness, whatever that means, are preferable, but I will gladly
accept all information, even rumors, about any such programs.
Thanks,
Steve Ford
G.TI.CSL@UTEXAS
(Please include my name in the subject field of your reply.)
-------
∂27-Jul-84 1244 Moon@SCRC-QUABBIN.ARPA validation suite (Steve Ford)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Jul 84 12:44:23 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 67077; Fri 27-Jul-84 15:21:22-EDT
Redistributed-date: Fri, 27 Jul 84 15:22 EDT
Redistributed-to: common-lisp@SU-AI.ARPA
Date: Fri, 27 Jul 84 13:38 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Subject: validation suite (Steve Ford)
To: G.TI.CSL@UTEXAS-20.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 27 Jul 84 09:23-EDT from G.TI.CSL at UTEXAS-20
Message-ID: <840727133853.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri 27 Jul 84 08:23:35-CDT
From: G.TI.CSL@UTEXAS-20.ARPA
I am looking for programs developed to VALIDATE an implementation's
conformance to the Common Lisp specification. Those with an aura of
OFFICIALness, whatever that means, are preferable, but I will gladly
accept all information, even rumors, about any such programs.
I sent an unoffical program that checks just the division functions (of which
there are more than ten in Common Lisp) to Richard Gabriel (RPG at SU-AI) for
the yellow pages about ten months ago. You can ask him what happened to it.
Thanks,
Steve Ford
G.TI.CSL@UTEXAS
(Please include my name in the subject field of your reply.)
Since most reply commands copy the subject, in the future you should include
your name in the subject field of -your- message.
∂02-Aug-84 0737 DLW@SCRC-STONY-BROOK.ARPA Data General
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 2 Aug 84 07:37:35 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 68263; Thu 2-Aug-84 10:39:07-EDT
Date: Thu, 2 Aug 84 10:37 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: Data General
To: quinquevirate@SU-AI.ARPA
cc: tk@SCRC-RIVERSIDE.ARPA, jlk@SCRC-RIVERSIDE.ARPA,
h@SCRC-RIVERSIDE.ARPA, spoerl@SCRC-RIVERSIDE.ARPA,
hirsch@SCRC-RIVERSIDE.ARPA, cwh@SCRC-RIVERSIDE.ARPA,
schofield@SCRC-RIVERSIDE.ARPA, mmcm@SCRC-RIVERSIDE.ARPA,
bsg@SCRC-RIVERSIDE.ARPA
Message-ID: <840802103731.1.DLW@CHICOPEE.SCRC.Symbolics>
I just got a call from Dan Oldman of Data General, in North Carolina,
who claims to be the product manager for Common Lisp. He heard about
the Common Lisp meeting at AAAI and was calling to find out when it was
(I told him). He intends to show up, and so we should have a good
opportunity to ask him questions. The main thing I found out is that
the Common Lisp that DG will be demonstrating at the conference is one
that they did themselves based on the SPICE code, rather than the Kyoto
Common Lisp implementation. (This is consistent with what Hagiya-san
told me a couple of weeks ago.) Unfortunately, Oldman has no way to
receive Arpanet mail, but perhaps we can talk to him about how DG can be
kept in the loop regarding further developments in the Common Lisp world.
∂02-Aug-84 1514 RPG Common Lisp Meeting
To: quinquevirate@SU-AI.ARPA
DARPA is proposing a Common Lisp meeting at the Naval Postgraduate School
in Monterey, California, on September 18th and 19th.
Here is the note I sent to Ohlander in response to the question of
whom to invite and the possible topics. Note they were interested in
companies coming to listen to the discusson. Please send any suggestions to
me, especially if I forgot to invite someone:
Here is a list of invitees, to which I might add more names if I think of them
at the Lisp Conference. There are companies included, although some names I've
suggested cover those companies. Also, wrote down some agenda items.
See you next week.
The following are the main designers of Common Lisp:
Guy L. Steele, Tartan Labs
Scott Fahlman, CMU
David Moon, Symbolics
Daniel Weinreb, Symbolics
Dick Gabriel, Stanford; LLNL
These people ought to be specifically invited, in addition to the companies
or organizations they represent:
John McCarthy, Stanford
Alan Bawden, MIT
Howard I. Cannon, Symbolics
Eric Bencson, Consultant to IntelliCorp
Martin Griss, HP
Bob Kessler, University of Utah
Rodney Brooks, Stanford
David Dill, CMU
Dave Dyer, ISI
Joseph Ginder, Perq Systems
Charles Hedrick, Rutgers
Bill Scherlis, CMU
Jon L. White, Xerox PARC
Bill vanMelle, Xerox PARC
Larry Masinter, Xerox PARC
Richard J. Fateman, UC Berkeley; Franz Inc.
Daniel Oldman, Data General, Research Triangle Park
Bernard S. Greenberg, Symbolics
John Foderaro, Franz Inc.
Skef Wholey, CMU; Perq Systems
Gary Brown, DEC
Walter Vanroggen, DEC
Texas Instruments
University of Texas, Austin
Glenn S. Burke, MIT
Kent Pitman, MIT
Richard Greenblatt, LMI
George Carrette, LMI
Jonathon Rees, MIT (formerly of Yale, currently at DECWRL)
These Universities should be invited to send a representative:
Stanford University
MIT
CMU
Rutgers
USC/ISI
University of Utah
University of Indiana
These companies ought to be invited:
TI
Apollo
SUN
DEC
Tektronix
LMI
Symbolics
Data General
BBN
Denelcor
Tartan
Thinking Machines
Franz Inc.
Gold Hill, Cambridge, Mass
Expertelligence, Southern California
IBM
HP
Xerox
Schlumberger
The following topics are suggested:
How do criticisms from outside the Common Lisp Committee pass to the committee?
Portable Environments
Object-oriented Programming
Portable Windows - is this a good idea, and when?
ANSI standardization
Server/Workstation concept for Lisp engines
Remote User Interfaces, remote windows.
Subsets and Supersets of Common Lisp - are they approved and how?
Multiprocessing extensions to Common Lisp for the Strategic Computing program
Validation of advertised Common Lisps
How should `Common Lisp Compatability Packages' be regarded? As Common Lisps?
∂02-Aug-84 1948 FAHLMAN@CMU-CS-C.ARPA Common Lisp Meeting
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Aug 84 19:48:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 2 Aug 84 22:48:50-EDT
Date: Thu, 2 Aug 1984 22:48 EDT
Message-ID: <FAHLMAN.12036372483.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Common Lisp Meeting
In-reply-to: Msg of 2 Aug 1984 18:14-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
It is crazy for DARPA to try to pull off a meeting of this size with
only a month's notice. They seem to enjoy pulling people's chains just
to watch them jump. Is there any clear need for such haste?
In any event, I probably won't be able to make a west coast meeting on
the dates proposed. I can send a proxy, I guess.
-- Scott
∂03-Aug-84 2356 FAHLMAN@CMU-CS-C.ARPA [decvax!mulga!bruce.csirovlsi: Apparent Commonlisp stupidity]
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Aug 84 23:56:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 4 Aug 84 02:56:36-EDT
Date: Sat, 4 Aug 1984 02:56 EDT
Message-ID: <FAHLMAN.12036679738.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: [decvax!mulga!bruce.csirovlsi: Apparent Commonlisp stupidity]
Date: Friday, 3 August 1984 02:29-EDT
From: decvax!mulga!bruce.csirovlsi at Berkeley
Re: Apparent Commonlisp stupidity
Apparently-To: fahlman@cmu-cs-a.arpa
Scott,
Please pass this on to the right forum. I think you'll find it sensible.
On page 444 of "Common Lisp," the representation of timeZone in decoded time
is defined as an integer specifying the number of hours west of GMT. However,
significant parts of Australia and PNG are at +10:30, ie, on a half-hour
boundary. Further, other parts of Australia, and some Pacific nations, are on
15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so
that "The sun rose first on Tonga" and so that sol was directly and precisely
overhead (on the mean) at noon.
This is no laughing matter. If Arpa standards have defined Commonlisp's
definition of timeZone, then we can blame them when a Commonlisp-based
early-warning system at Pine Gap causes a launch-on-warning attack 1/2 hour
before the Pentagon is notified. (Pine Gap, near the Alice, and Exmouth, on
the Northwest Cape, are America's two shoot-first, ask-later bases in Oz.) No,
I don't think this would really happen. But unless Arpa has constrained the
definition, I think that Commonlisp's developers need to review timeZones
using global time considerations. Perhaps what is needed is a formal zone
name (integers fine; characters better) and also the local offset
(hrs:mins:secs).
Closer to reality, DEC's Commonlisp implementation will soon be running in a
place with a half-hour offset. It will necessarily lie about its zone, and
this will make it impossible to compute time differences properly. (Consider,
for example, that the EST in this message is Australian, not Yank.) For comic
relief, we can note that VMS is sucking even more air than usual here, as it
STILL has no notion of zone or offset after six brain-damaged years.
On a lesser note, I believe that decoded time should include dayOfYear,
weekOfYear, and leapYearP, because they were necessarily computed (or already
available) to decode UT. Be complete and consistent when there's no extra
cost, eh? Also, I find that, in EncodeUT and DecodeUT, the treatment of
daylight time and (local and other) zones is inconsistent.
Despite the occasional levity, Scott, my tone is serious. It's easy to be
parochial about time when there's three hours difference in an essentially
closed world. Living outside the US has given me tremendous insight here.
I'm ready for flak, but you'll miss unless you shoot on the half-hour.
Cheers,
Bruce (Nelson)
∂05-Aug-84 1110 RAM@CMU-CS-C.ARPA *print-case* and *print-escape*
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Aug 84 11:10:38 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 5 Aug 84 14:09:57-EDT
Date: Sun, 5 Aug 1984 14:09 EDT
Message-ID: <RAM.12037064449.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: *print-case* and *print-escape*
Should *print-case* and *print-escape* interact? In says in the
CLM is several places that when *print-escape* is NIL, a symbol is
printed simply as the characters in its name.
If I set *print-case* to :downcase because I like Unix and then do
a (princ '|This is a program ported from MACLISP.|) should that print
as:
this is a program ported from maclisp.
Rob
∂13-Aug-84 0944 Moon@SCRC-STONY-BROOK.ARPA *print-case* and *print-escape*
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:42:40 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71053; Mon 13-Aug-84 00:44:21-EDT
Date: Mon, 13 Aug 84 00:43 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: *print-case* and *print-escape*
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12037064449.BABYL@CMU-CS-C.ARPA>
Message-ID: <840813004306.0.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sun, 5 Aug 1984 14:09 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Should *print-case* and *print-escape* interact? In says in the
CLM is several places that when *print-escape* is NIL, a symbol is
printed simply as the characters in its name.
My belief is that this is just an oversight in the manual (text not updated
when *print-case* was installed) and that the printer option variables should
be handled orthogonally as much as possible. Thus
(write 'foo :escape nil :case :downcase) should print a lowercase foo, as it
does in our implementation.
If I set *print-case* to :downcase because I like Unix and then do
a (princ '|This is a program ported from MACLISP.|) should that print
as:
this is a program ported from maclisp.
Yes. It's not Maclisp-compatible if *print-case* isn't :upcase.
∂13-Aug-84 0953 Moon@SCRC-STONY-BROOK.ARPA Timezones offset by non-integral hours
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:52:25 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71058; Mon 13-Aug-84 00:57:57-EDT
Date: Mon, 13 Aug 84 00:56 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Timezones offset by non-integral hours
To: Common-Lisp@SU-AI.ARPA, decvax!mulga!bruce.csirovlsi@UCB-VAX.ARPA,
bug-lispm@SCRC-RIVERSIDE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12036679738.BABYL@CMU-CS-C.ARPA>
Message-ID: <840813005637.1.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sat, 4 Aug 1984 02:56 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Date: Friday, 3 August 1984 02:29-EDT
From: decvax!mulga!bruce.csirovlsi at Berkeley
Re: Apparent Commonlisp stupidity
On page 444 of "Common Lisp," the representation of timeZone in decoded time
is defined as an integer specifying the number of hours west of GMT. However,
significant parts of Australia and PNG are at +10:30, ie, on a half-hour
boundary. Further, other parts of Australia, and some Pacific nations, are on
15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so
that "The sun rose first on Tonga" and so that sol was directly and precisely
overhead (on the mean) at noon.
I believe that Common Lisp ought to allow the timezone to be a non-integral number
of hours, accepting either a floating-point number or a ratio, as our implementation
does.
BUG-LISPM: Too bad this doesn't actually work in our implementation!
The code looks like it used to work, and then someone "improved" the
code for TIME:DECODE-UNIVERSAL-TIME-WITHOUT-DST to try to avoid excess
consing by using fixnum-specific operations. We need to fix this.
...Perhaps what is needed is a formal zone
name (integers fine; characters better) and also the local offset
(hrs:mins:secs).
We have some approximation to this, which has succeeded in convincing me
that the world is not in sufficient agreement on names of timezones to justify
enshrining any particular set of names in a standard language specification.
On a lesser note, I believe that decoded time should include dayOfYear,
weekOfYear, and leapYearP, because they were necessarily computed (or already
available) to decode UT. Be complete and consistent when there's no extra
cost, eh?
I have no particular opinion about this.
Also, I find that, in EncodeUT and DecodeUT, the treatment of
daylight time and (local and other) zones is inconsistent.
I agree and have already complained to Guy about this. I suspect it's just
typographical errors in the manual, but he didn't reply to my queries.
When we're done with this discussion we can address parameterization of the dates
when daylight savings time turns on and off!
∂13-Aug-84 0953 Moon@SCRC-STONY-BROOK.ARPA Timezones offset by non-integral hours
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 09:52:25 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 71058; Mon 13-Aug-84 00:57:57-EDT
Date: Mon, 13 Aug 84 00:56 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Timezones offset by non-integral hours
To: Common-Lisp@SU-AI.ARPA, decvax!mulga!bruce.csirovlsi@UCB-VAX.ARPA,
bug-lispm@SCRC-RIVERSIDE.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12036679738.BABYL@CMU-CS-C.ARPA>
Message-ID: <840813005637.1.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sat, 4 Aug 1984 02:56 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Date: Friday, 3 August 1984 02:29-EDT
From: decvax!mulga!bruce.csirovlsi at Berkeley
Re: Apparent Commonlisp stupidity
On page 444 of "Common Lisp," the representation of timeZone in decoded time
is defined as an integer specifying the number of hours west of GMT. However,
significant parts of Australia and PNG are at +10:30, ie, on a half-hour
boundary. Further, other parts of Australia, and some Pacific nations, are on
15 and 20 minute boundaries. Finally, at one time Tonga was +12:19:12, so
that "The sun rose first on Tonga" and so that sol was directly and precisely
overhead (on the mean) at noon.
I believe that Common Lisp ought to allow the timezone to be a non-integral number
of hours, accepting either a floating-point number or a ratio, as our implementation
does.
BUG-LISPM: Too bad this doesn't actually work in our implementation!
The code looks like it used to work, and then someone "improved" the
code for TIME:DECODE-UNIVERSAL-TIME-WITHOUT-DST to try to avoid excess
consing by using fixnum-specific operations. We need to fix this.
...Perhaps what is needed is a formal zone
name (integers fine; characters better) and also the local offset
(hrs:mins:secs).
We have some approximation to this, which has succeeded in convincing me
that the world is not in sufficient agreement on names of timezones to justify
enshrining any particular set of names in a standard language specification.
On a lesser note, I believe that decoded time should include dayOfYear,
weekOfYear, and leapYearP, because they were necessarily computed (or already
available) to decode UT. Be complete and consistent when there's no extra
cost, eh?
I have no particular opinion about this.
Also, I find that, in EncodeUT and DecodeUT, the treatment of
daylight time and (local and other) zones is inconsistent.
I agree and have already complained to Guy about this. I suspect it's just
typographical errors in the manual, but he didn't reply to my queries.
When we're done with this discussion we can address parameterization of the dates
when daylight savings time turns on and off!
∂14-Aug-84 1059 STEELE@TL-20A.ARPA Requests for clarification
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 14 Aug 84 10:58:47 PDT
Received: ID <STEELE@TL-20A.ARPA>; Tue 14 Aug 84 13:54:47-EDT
Date: Tue 14 Aug 84 13:54:45-EDT
From: STEELE@TL-20A.ARPA
Subject: Requests for clarification
To: common-lisp@SU-AI.ARPA
The following requests for clarification were received from
a few people at Data General:
For a stream constructed with make-two-way-stream, what is the result
of applying stream-element-type to the stream, especially if the
element-types of the two underlying streams are different?
Under make-concatenated-stream, it should be made clear (if it is indeed
the case) that the resulting stream delivers to its clients only one
eof, after the contents of all the subsidiary streams have been
deleivered; the eofs from all but the last stream are not delivered.
How does the close function operate on various non-primitive streams?
For example, does close of a two-way stream close the two underlying
streams? What about close of a concatenated stream?
As a concatenated stream hits eof on each subsidiary stream, are those
subsidiary streams closed?
Some statement about "constant" list structures in compiled code
needs to be made. Many implementations would like to place constant
list structure, particularly constants in compiled code, in read-only
memory. (MacLISP does this.) This would mean that an expression such
as (nconc '(a b c) x) would be illegal, at least in a program to be
compiled.
An explicit statement should be made as to how equal and equalp treat
structures. DO structures fall under the general heading of "objects
that have components"?
--Guy
-------
∂15-Aug-84 1614 RPG Validation through Litigation
To: quinquevirate@SU-AI.ARPA
What do you guys think of this idea? It's a little radical, but it
has its merits:
∂11-Aug-84 2142 ANDY@SU-SCORE.ARPA Common Lisp verification
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Aug 84 21:42:21 PDT
Date: Sat 11 Aug 84 21:41:03-PDT
From: Andy Freeman <ANDY@SU-SCORE.ARPA>
Subject: Common Lisp verification
To: rpg@SU-AI.ARPA
Why not take a hint from the way RF shielding is regulated? That is
enforced by the competitors. They sue each other for triple damages
if the requirements aren't met.
Obviously this can't work directly, but a simple modification should.
Let each implementor register his version's existence (and admitted
shortcomings) with Steele and have them tear into each other. All
Steele has to do is maintain a list of verified discrepancies. Since
the discrepancies are submitted with a program which demonstrates the
problem, a verification suite should quickly emerge. (It can be used
to shortcut the process later. I don't know how public it should be.)
Some people are going to try to restrict access by other implementors
(and Steele) to avoid taking their shots. That too can be noted in
Steele's records.
All it takes is a page explaining the process in the next printing of
the Common Lisp manual. As a user, I'll send a stamped self-addressed
envelope (possibly with a modest processing fee, say $5) to him with
my request for the current records. Registering implementors pay a
slightly higher fee. Complaining implementors (or even disgruntled
users) merely send in a program which demonstrates the problem. The
verified problem is not only registered but forwarded to the offending
implementors (which may be the complainants).
This has to be done with some care to avoid legal problems and other
details, ie de-registration, but it can be started immediately. It's
hard to imagine anything that will take less effort by the Common Lisp
committee.
-andy
-------
∂15-Aug-84 1821 JonL.pa@Xerox.ARPA Re: bug in assoc
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Aug 84 18:21:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 15 AUG 84 18:18:31 PDT
Date: 15 Aug 84 18:18 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: bug in assoc
In-reply-to: "smh@mit-ems"@MIT-MC.ARPA's message of 14 Aug 84 17:13:29
EDT
To: "smh@mit-ems"@MIT-MC.ARPA
cc: "mcgeer@ucbkim"@UCB-VAX.ARPA, franz-friends@UCB-VAX.ARPA,
"jmiller@ct.csnet@udel-relay"@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
Common Lisp also faces the possibility of inconsistent system code due
to the handling of cases marked "is an error" (see Manual, sec. 1.2.4);
that is, it is undefined as to what happens if you apply CAR to a
non-LISTP. All portable system code should therefore certify the type
of a datum before taking car or cdr. ASSOC (and ASSQ) from the Franz
sources clearly doesn't check the type of the arguments before carcdring
away on them.
Well, why not "all system code should certify the type before taking
car/cdr . . . " -- it certainly can't hurt to "signal an error" rather
than fall into some undefined morass.
-- JonL --
∂15-Aug-84 1940 FAHLMAN@CMU-CS-C.ARPA Validation through Litigation
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Aug 84 19:40:11 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 15 Aug 84 22:37:53-EDT
Date: Wed, 15 Aug 1984 22:37 EDT
Message-ID: <FAHLMAN.12039778362.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Validation through Litigation
In-reply-to: Msg of 15 Aug 1984 19:14-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
I think that it's a terrible idea to promote competitive finger-pointing
as the tool for standardizing Common Lisp. We want the companies to
feel good about being part of the "Common Lisp Community" and we want to
encourage good-faith efforts to adhere to the standard without making
this a matter of fear and loathing. I think that the proposed scheme
would bring out the very worst in everyone associated with it.
-- Scott
∂15-Aug-84 1944 RPG Just....
To: quinquevirate@SU-AI.ARPA
passing on a suggestion made to me...
There is another issue I just became aware of: How do manufacturers
outside the US get source code from us, given that US Customs might
not necessarily approve?
-rpg-
∂15-Aug-84 2018 FAHLMAN@CMU-CS-C.ARPA Just....
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Aug 84 20:18:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 15 Aug 84 23:16:32-EDT
Date: Wed, 15 Aug 1984 23:16 EDT
Message-ID: <FAHLMAN.12039785392.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Just....
In-reply-to: Msg of 15 Aug 1984 22:44-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Several versions of our code have made it overseas. Given the totally
chaotic state of regulation on this, I have never tried to face the
issue head-on and get a ruling. So far, we haven't actually shipped a
tape to anyone overseas, but have just let them "take" our code over
whatever network access they can arrange, just as U.S. companies do.
For example, the Kyoto University group got our code from Data General
of Japan who in turn got it from American DG, who got it from us.
Europeans usually arrange to access our files over the UC London TIP, or
sometimes make a tape when they're visiting someplace in the U.S. and
carry it back themselves. Our public-domain code is sitting unprotected
on an Arpanet machine and is in the possession of several U.S.
companies, so we can't very well control where it ends up. Of course,
the foreigners get nothing from us that is not freely available to U.S.
companies and researchers.
I suppose this cavalier attitude might eventually get me into real
trouble, but so far I've heard no rumblings. I'd rather act in good
faith to promote Common Lisp as an international standard than to let
some bureaucrat hold the whole process up for a few years while he's
covering his ass.
-- Scott
∂17-Aug-84 1143 RPG DARPA
To: quinquevirate@SU-AI.ARPA
I sent out a message 2 weeks ago stating that they were proposing a meeting.
From what I can gather, they hemmed and hawed while Squires and Ohlander
figured out when *they* could make it to Monterey. For me, Monterey is
convenient, and so I haven't felt the crunch that you guys did.
To make this note have some content, let me state that Ohlander is
also going to propose that the 5 of us and maybe some others should constitute
a Common Lisp `Executive Committee' which Ohlander will chair to make
`official' decisions like manual changes at one end and validation suite
decisions (or delegations) at the other end. I told him I'd run this by you
before Monterey to get you thinking about it. I've just surfaced from
recovering from trip-itis and the flu, otherwise I would have mentioned this
earlier.
-rpg-
∂17-Aug-84 1506 DLW@SCRC-STONY-BROOK.ARPA DARPA
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 15:05:54 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 73928; Fri 17-Aug-84 18:05:25-EDT
Date: Fri, 17 Aug 84 18:05 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: DARPA
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 17 Aug 84 14:43-EDT from Dick Gabriel <RPG at SU-AI>
Message-ID: <840817180510.9.DLW@CHICOPEE.SCRC.Symbolics>
I also would have preferred delaying the meeting somewhat, but I can
make it.
Does Ohlander know enough about Lisp that he would understand the
implications of proposed manual changes? Perhaps he feels that the main
thing that's needed is a vote-counter who will be perceived as impartial
by the outside world. I'm a little uncomfortable about Ohlander, partly
because I don't know him, but probably anybody who I do know would not
be considered impartial, as seen by an outsider. The fact that he's
from the military makes me wonder how well he'll be able to deal with
our highly informal style, but again since I don't know him, I can't tell
whether this is likely to be a problem or not.
∂18-Aug-84 1124 Moon@SCRC-QUABBIN.ARPA declarations in body of LABELS
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 11:23:53 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 72691; Sat 18-Aug-84 14:23:25-EDT
Date: Sat, 18 Aug 84 14:23 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: declarations in body of LABELS
To: Steele@TL-20B.ARPA
cc: Common-Lisp@SU-AI.ARPA
Message-ID: <840818142354.4.MOON@EUPHRATES.SCRC.Symbolics>
Pages 113 and 154 disagree about whether a declaration may appear in the
body of a LABELS (or FLET or MACROLET). These forms do not bind variables,
but I assume that page 154 is correct. Example:
(LABELS ((FOO (X Y) (IF X (LIST X Y) Y)))
(DECLARE (INLINE FOO))
(COND ((... (FOO 1 2) ...))))
∂18-Aug-84 1622 RAM@CMU-CS-C.ARPA Requests for clarification
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 16:21:59 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 18 Aug 84 19:20:03-EDT
Date: Sat, 18 Aug 1984 19:19 EDT
Message-ID: <RAM.12040528780.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: STEELE@TL-20A.ARPA
Cc: common-lisp@SU-AI.ARPA
Subject: Requests for clarification
In-reply-to: Msg of 14 Aug 1984 13:54-EDT from STEELE at TL-20A.ARPA
For a stream constructed with make-two-way-stream, what is the result
of applying stream-element-type to the stream, especially if the
element-types of the two underlying streams are different?
In Spice Lisp, Stream-Element-Type returns an Or of the distinct
stream element types for the component streams if they are different.
obviously lazy implementor could return T.
How does the close function operate on various non-primitive streams?
For example, does close of a two-way stream close the two underlying
streams? What about close of a concatenated stream?
In Spice Lisp, closing any multiple stream results in closing all of
the component streams.
As a concatenated stream hits eof on each subsidiary stream, are those
subsidiary streams closed?
Spice Lisp doesn't do this, and I think that's the right thing to
do. In the case of a file stream, hitting eof doesn't necessarily
make the stream useless, so you don't want to go around automatically
closing the things.
An explicit statement should be made as to how equal and equalp treat
structures. DO structures fall under the general heading of "objects
that have components"?
There better dammn well be some predicate that works on structures,
so I guess it's got to be equalp. I guess we could make equal work on
structures as a special case, but that would have interactions with
structure typedness.
Rob
∂18-Aug-84 2135 Moon@SCRC-STONY-BROOK.ARPA Requests for clarification
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 21:34:13 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 74301; Sun 19-Aug-84 00:34:22-EDT
Date: Sun, 19 Aug 84 00:33 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Requests for clarification
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: STEELE@TL-20A.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12040528780.BABYL@CMU-CS-C.ARPA>
Message-ID: <840819003302.6.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sat, 18 Aug 1984 19:19 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
We haven't bothered too much yet about implementing the four types of
multiple streams (broadcast, concatenated, two-way, and echo) since they
are ill-specified and not terribly useful (i.e. we'll do them, but they
aren't high priority).
For a stream constructed with make-two-way-stream, what is the result
of applying stream-element-type to the stream, especially if the
element-types of the two underlying streams are different?
In Spice Lisp, Stream-Element-Type returns an Or of the distinct
stream element types for the component streams if they are different.
obviously lazy implementor could return T.
This seems reasonable to me.
How does the close function operate on various non-primitive streams?
For example, does close of a two-way stream close the two underlying
streams? What about close of a concatenated stream?
In Spice Lisp, closing any multiple stream results in closing all of
the component streams.
This seems reasonable to me, although I can think of arguments (from experience
on Multics for instance) against it.
As a concatenated stream hits eof on each subsidiary stream, are those
subsidiary streams closed?
Spice Lisp doesn't do this, and I think that's the right thing to
do. In the case of a file stream, hitting eof doesn't necessarily
make the stream useless, so you don't want to go around automatically
closing the things.
I assume that if you try to read past EOF on a subsidiary stream it advances
to the next stream, but lets you FILE-POSITION back into earlier streams?
Then none of the component streams are closed until the concatenated stream
is closed. This seems reasonable.
An explicit statement should be made as to how equal and equalp treat
structures. DO structures fall under the general heading of "objects
that have components"?
There better dammn well be some predicate that works on structures,
so I guess it's got to be equalp. I guess we could make equal work on
structures as a special case, but that would have interactions with
structure typedness.
In our system EQUAL and EQUALP treat structures the same as arrays. This
seems the most consistent with the manual pp.80-82. Thus EQUAL is never true
for structures unless EQ is, and EQUALP is true for structures of the same
type with the same components. This is all assuming you don't use the :TYPE
option to DEFSTRUCT.
∂18-Aug-84 2138 Moon@SCRC-STONY-BROOK.ARPA Requests for clarification
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 21:38:13 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 74303; Sun 19-Aug-84 00:38:27-EDT
Date: Sun, 19 Aug 84 00:37 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Requests for clarification
To: STEELE@TL-20A.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 14 Aug 84 13:54-EDT from STEELE at TL-20A
Message-ID: <840819003720.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: Tue 14 Aug 84 13:54:45-EDT
From: STEELE@TL-20A.ARPA
Some statement about "constant" list structures in compiled code
needs to be made. Many implementations would like to place constant
list structure, particularly constants in compiled code, in read-only
memory. (MacLISP does this.) This would mean that an expression such
as (nconc '(a b c) x) would be illegal, at least in a program to be
compiled.
I suggest that this be explicitly forbidden. I don't think the compiler
should undertake to guarantee how much sharing of constant list structure
with constants in the same or other functions it will do or not do.
I also suggest that even constants created with #, be explicitly forbidden
to be modified since after load time they cannot be distinguished from normal
constants. Constants should not be used as a substitute for global variables,
in my opinion.
∂19-Aug-84 1408 RPG Meeting
∂02-Aug-84 2055 FAHLMAN@CMU-CS-C.ARPA Meeting
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Aug 84 20:54:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 2 Aug 84 23:55:05-EDT
Date: Thu, 2 Aug 1984 23:55 EDT
Message-ID: <FAHLMAN.12036384547.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Meeting
In-reply-to: Msg of 2 Aug 1984 22:51-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
OK, I'll see you at AAAI and we can discuss many things then. I arrive
Tuesday afternoon and leave Friday afternoon.
As for the DARPA meeting, I'm probably just grumpy from having spent
about 20 hours travelling and waiting to travel today, and then another
three hours trying to catch up on netmail. But it really does seem that
DARPA meetings are always "Gee, we're sorry about the short notice, but
you've really got to fly to Guam for an important meeting the day after
tomorrow, because some decisions have to be made right away and our
crowded schedules only have that one slot available." That's OK once in
a while -- sometimes things do come up that are genuinely unpredictable
and require quick action -- but it seems to have become a habit in some
quarters. My schedule for September is just about full, October is
beginning to fill, and from then on it's pretty open. I bet that's true
of most of the others on your list. If it were just three or four of us
that had to get together we could probably find a time in September by
negotiation, but a bigger meeting has to be a "take it or leave it"
date, so it had better be far enough out that people's calendars are not
clogged.
Switzerland was great, but we only got one clear day on the Bernese leg
of the trip and we decided to hack the Jungfrau rather than heading
toward Gimmelwald. It's on my list for next time, though.
Cheers,
Scott
∂19-Aug-84 1411 RPG CLCRIT and numerics
∂04-Aug-84 1544 fateman%ucbdali@Berkeley CLCRIT and numerics
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 4 Aug 84 15:44:43 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.28/4.33)
id AA14589; Sat, 4 Aug 84 15:43:00 pdt
Received: by ucbdali.ARPA (4.24/4.27)
id AA27885; Sat, 4 Aug 84 15:44:35 pdt
Date: Sat, 4 Aug 84 15:44:35 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8408042244.AA27885@ucbdali.ARPA>
To: rpg@su-ai
Subject: CLCRIT and numerics
If people in the UNIX world correct the math library (and include complex),
then Franz (and perhaps UNIX Common Lisp) can just use that. Unfortunately,
CL has probably deviated from what the corrected library will do, at least
if Prof. Kahan's routines are provided for complex elementary functions.
The CL book specifies both too much and too little.
I found your paper to be interesting and perceptive. I hope it provokes some
discussion!
∂19-Aug-84 1415 RPG CDC Common Lisp
∂13-Aug-84 2125 hudson%umass-cs.csnet@csnet-relay.arpa CDC Common Lisp
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 13 Aug 84 21:24:55 PDT
Received: From umass-cs.csnet by csnet-relay; 14 Aug 84 0:10 EDT
Date: Mon, 13 Aug 84 19:03 EST
From: Rick Hudson <hudson%umass-cs.csnet@csnet-relay.arpa>
To: rpg@su-ai.arpa
Subject: CDC Common Lisp
Richard,
I want to be involved in any worthwhile meetings about Common Lisp.
As far as the technicl issues concerning the CDC Common Lisp effort
I have complete control. If the meeting will include any passing
of the hat for funding it will mean me haveing to tgo back to CDC
with requests and suggestinons. If I nknew what was going to
take place maybe I could get an indication of where CDC stood.
Also if you could send me the bench marks I wuould like to
run themASA ASAP..
USnamil address
Thanks,
Rick
∂19-Aug-84 1417 RPG Ohlander
∂14-Aug-84 1335 FAHLMAN@CMU-CS-C.ARPA Ohlander
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Aug 84 13:34:52 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 14 Aug 84 16:29:26-EDT
Date: Tue, 14 Aug 1984 16:28 EDT
Message-ID: <FAHLMAN.12039448983.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: rpg@SU-AI.ARPA
Subject: Ohlander
Dick,
What's the right net address for Ron Ohlander? I need to impress upon
him that if he is going to try for a meeting on September 18 and 19, the
word has to go out RIGHT NOW. It's already too late, actually, but if
I move lots of things around I can make it. But I've got to start
moving things right away.
-- Scott
Ohlander@isi works.
∂19-Aug-84 1419 RPG Common Lisp meeting
∂14-Aug-84 2011 FAHLMAN@CMU-CS-C.ARPA Common Lisp meeting
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Aug 84 20:11:18 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 14 Aug 84 23:09:12-EDT
Date: Tue, 14 Aug 1984 23:09 EDT
Message-ID: <FAHLMAN.12039521921.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: ohlander@USC-ISI.ARPA
Cc: rpg@SU-AI.ARPA
Subject: Common Lisp meeting
Ron,
I first heard about the proposed Common Lisp meeting in Monterrey a
little over a week ago in netmail from Dick Gabriel. At the time I said
that I didn't think I could get there on the dates specified, September
18 and 19. I also told Gabriel that I thought that, given the number of
people and companies being invited from far away, a month's notice was
not sufficient. Dick said he'd pass these comments on to you; I don't
know if he did this. I know that many weighty issues need to be sorted
out as soon as possible, but if the meeting is called on such short
notice that most of the key players can't come, any decisions made will
be worthless.
As it turns out, I will be able to move things around in order to make a
meeting on 9/18 - 9/19, but only if I begin right now to shuffle things
around and arrange for people to cover things for me. If the meeting is
to be held at that time, I would appreciate getting some confirmation of
this RIGHT AWAY. I think the other folks on the list have equally busy
schedules and would also like a few weeks' notice.
If the meeting is moved to a later time, but is still going to be in
California, may I suggest that it be a Monday/Tuesday? That way people
can arrange things so that they miss only two or three days of work
instead of four. I bet more people could come in that case. I'd also
suggest moving the meeting to the East Coast somewhere, but I guess the
proposed attendees are about equally split East and West.
For what it's worth, I definitely can't come if it is on the week of
October 22nd, but most other dates in October and November are possible
for me, given reasonable advance notice.
One last point: Gabriel's list included one or two people from Perq
Systems, but they were omitted from the list of companies to be invited.
-- Scott
∂19-Aug-84 1430 RPG possible common lisp meeting on iterative notations
∂16-Aug-84 1336 @MIT-MC:Dick@MIT-MC possible common lisp meeting on iterative notations
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 16 Aug 84 13:36:45 PDT
Date: Thu, 16 Aug 1984 16:32 EDT
Message-ID: <DICK.12039974028.BABYL@MIT-OZ>
Sender: DICK%MIT-OZ@MIT-MC.ARPA
From: Dick@MIT-MC
to: guy.steele@CMU-CS-A.ARPA, rpg@SU-AI.ARPA
Subject: possible common lisp meeting on iterative notations
In-reply-to: Msg of 15 Aug 1984 16:49-EDT from Kent M Pitman <kmp at MIT-MC>
I have heard conflicting rumors that there may or may not soon be a
common lisp meeting that will explicitly consider possible iterative
constructs in common lisp. If there is going to be such a meeting I
would like very much to present my expressional loop notation which
has recently been redesigned based on the experiance of the last year.
Dick Waters
∂19-Aug-84 1434 RPG The Monterey CL Conference
∂16-Aug-84 1544 spoerl@SCRC-QUABBIN.ARPA The Monterey CL Conference
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 16 Aug 84 15:44:26 PDT
Received: from WAIKATO by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 72025; Thu 16-Aug-84 18:43:47-EDT
Received: from SCC-YOSEMITE by WAIKATO via CHAOS with CHAOS-MAIL id 46270; Thu 16-Aug-84 18:44:00-EDT
Date: Thu, 16 Aug 84 18:42 EDT
From: Jim Spoerl <spoerl@SCRC-RIVERSIDE.ARPA>
Subject: The Monterey CL Conference
To: rpg@SU-AI.ARPA
Hi Dick-
As Tony Schofield and I mentioned to you the other week, we would very
much like to attend the conference. Is there anything we (or you) can
do to make this possible? I had the understanding that DARPA was
sending out the invitations.
Also, do you know yet when and where your benchmarks will be published?
-Jim
I think that every company can send some marketing-type people in addition
to a technical person. I will send a request that you be invited to Ohlander.
-rpg-
Invite
Ron,
Please invite Jim Spoerl from Symbolics to the CL meeting.
-rpg-
∂19-Aug-84 1436 RPG Re: Common Lisp meeting
∂17-Aug-84 0523 OHLANDER@USC-ISI.ARPA Re: Common Lisp meeting
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 05:23:39 PDT
Date: 17 Aug 1984 08:18-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: Common Lisp meeting
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: rpg@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]17-Aug-84 08:18:30.OHLANDER>
In-Reply-To: <FAHLMAN.12039521921.BABYL@CMU-CS-C.ARPA>
Scott,
We definitely plan to have the meeting on the 18th and 19th of
September in Monterey, CA. I originally intended to give at least
two months notice but time kept slipping away as I tried to coordinate
with key players. The biggest problem has been commitments of myself
and Steve Squires. I have gone through some trouble to line up the
Naval Postgraduate School and it would be embarassing to cancel out
now.
I agree that the key players have to be there to get things accomplished.
That is why I asked Gabriel to notify them earlier than the others. It is
also important that the world gets informed on what DARPA's plans and
policies are. I don't want to delay in making this known. As you may
or may not know, some companies are making waves about supporting Common
Lisp, which is OK with me. The problem is that they object to us
levying CL as a standard. I want to nip these problems in the bud and
take a position that will be hard for us to back down from.
It is important that we have a public forum and general meeting so that
people cannot come back later and complain that they had no chance to
participate. Once we do this, I expect that a small number of people
will do the real work, as usual.
I am making sure that Perq gets an official letter.
Ron
P.S. Could you check and make sure that the handful of key players know about
the meeting. Letters are being sent out now but will require a few
days to get there.
∂19-Aug-84 1437 RPG Common Lisp meeting
∂17-Aug-84 0635 FAHLMAN@CMU-CS-C.ARPA Common Lisp meeting
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 06:35:32 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 Aug 84 09:33:31-EDT
Date: Fri, 17 Aug 1984 09:33 EDT
Message-ID: <FAHLMAN.12040159857.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: rpg@SU-AI.ARPA
Subject: Common Lisp meeting
In-reply-to: Msg of 17 Aug 1984 08:18-EDT from OHLANDER at USC-ISI.ARPA
OK, I'll get to this meeting one way or another. I've found someone to
cover the teaching I had scheduled for that time. I just hope that
enough of the others can make it so that it won't be a total waste of
time. RPG already sent the key people some mail, but I'll follow up a
bit.
-- Scott
∂19-Aug-84 1437 RPG Monterey
∂17-Aug-84 0644 FAHLMAN@CMU-CS-C.ARPA Monterey
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 06:44:09 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 Aug 84 09:41:51-EDT
Date: Fri, 17 Aug 1984 09:41 EDT
Message-ID: <FAHLMAN.12040161380.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: rpg@SU-AI.ARPA, ohlander@USC-ISI.ARPA
Subject: Monterey
It occurs to me that I've never been to Monterey and have no idea what's
the best way to get there or where to stay. Is DARPA going to reserve
some hotel rooms near the conference, or is it every man for himself?
If the latter, any suggestions about a reasonable hotel nearby? Is
there some airport really close to Monterey into which real airlines
fly, or it it just as easy to fly into SF and rent a car there? The
times I've tried to fly into San Jose ended up costing me far more time
than it would take to drive the extra distance, since connections from
Pittsburgh are flaky. Such details probably want to be passed on to all
the paticipants.
-- Scott
∂19-Aug-84 1437 RPG Re: Common Lisp meeting
∂17-Aug-84 0720 OHLANDER@USC-ISI.ARPA Re: Common Lisp meeting
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 07:20:43 PDT
Date: 17 Aug 1984 10:20-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: Common Lisp meeting
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: rpg@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]17-Aug-84 10:20:31.OHLANDER>
In-Reply-To: <FAHLMAN.12040159857.BABYL@CMU-CS-C.ARPA>
Scott,
Thanks for your efforts.
Ron
∂19-Aug-84 1438 RPG Re: Monterey
∂17-Aug-84 0757 OHLANDER@USC-ISI.ARPA Re: Monterey
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 07:57:17 PDT
Date: 17 Aug 1984 10:57-EDT
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: Monterey
From: OHLANDER@USC-ISI.ARPA
To: Fahlman@CMU-CS-C.ARPA
Cc: rpg@SU-AI.ARPA, ohlander@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA]17-Aug-84 10:57:01.OHLANDER>
In-Reply-To: <FAHLMAN.12040161380.BABYL@CMU-CS-C.ARPA>
Scott,
I usually fly into San Francisco or San Jose and drive down. It is
about a two hour drive from SF airport. United has flights
from both LA and SF to Monterey. Looking at the airline guide, I can see
that UA has one at 1:30 P.M. As far as hotels are concerned, you will be
getting a list of them with your invitation.
Ron
P.S. You will like Monterey. It is a beautiful area of the country.
∂19-Aug-84 1438 RPG Monterey
∂17-Aug-84 1002 FAHLMAN@CMU-CS-C.ARPA Monterey
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 10:02:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 Aug 84 12:59:49-EDT
Date: Fri, 17 Aug 1984 12:59 EDT
Message-ID: <FAHLMAN.12040197404.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: OHLANDER@USC-ISI.ARPA
Cc: rpg@SU-AI.ARPA
Subject: Monterey
In-reply-to: Msg of 17 Aug 1984 10:57-EDT from OHLANDER at USC-ISI.ARPA
OK, thanks for the travel info.
-- Scott
∂19-Aug-84 1438 RPG Monterey
∂17-Aug-84 1021 FAHLMAN@CMU-CS-C.ARPA Monterey
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 10:21:14 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 Aug 84 13:19:13-EDT
Date: Fri, 17 Aug 1984 13:18 EDT
Message-ID: <FAHLMAN.12040200885.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: steele%tartan@CMU-CS-C.ARPA
Subject: Monterey
In-reply-to: Msg of 17 Aug 1984 13:07-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
What are the precise plans with you and Steele? I'll be coming in
sometime Monday afternoon and will either take the redeye back
Wednesday night or a more civilized flight on Thursday. Right now it's
all flexible, so if I know what your plans are I can try to match them
when I make reservations. Driving down together might have some
advantages -- time to discuss things away from the others at the
meeting.
-- Scott
∂19-Aug-84 1440 RPG Steele
∂17-Aug-84 1054 FAHLMAN@CMU-CS-C.ARPA Steele
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 10:42:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 17 Aug 84 13:40:21-EDT
Date: Fri, 17 Aug 1984 13:40 EDT
Message-ID: <FAHLMAN.12040204758.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: Steele
In-reply-to: Msg of 17 Aug 1984 13:27-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Dick,
OK, I'll see if I can coordinate with Steele (or his secretary) on the
flight down there, and will plan to ride to Monterey with the two of
you. If I understand you correctly, you'll be coming back to Palo Alto
on Wednesday night, but probably won't want to go on to the airport that
night to deliver me. There's a 9:15pm flight out of Monterey that
connects with the redeye coming back, so I can get get you or somebody
else to drop me there Wednesday night I won't need to rent my own car.
Does that sound like the easiest way to do it all around?
-- Scott
∂19-Aug-84 1440 RPG
∂17-Aug-84 1128 RPG Monterey
To: "@INVITE.DIS[COM,LSP]"@SU-AI.ARPA
All of you have been invited to the DARPA-sponsored meeting which will be
held at the Naval Postgraduate School in Monterey, California, on
September 18 and 19. You will be receiving written invitations from DARPA
along with instructions on where it is and suggestions regarding where to
stay.
Monterey is about a 2-hour drive from San Francisco International Airport.
There are flights to Monterey on several carriers. For those who wish to
drive, go south on US 101 through San Jose and past Gilroy. Take route 156
west. Route 156 intersects US 1 a little north of Monterey. The first
Monterey exit is labelled `Pacific Grove.' The Naval Postgraduate School
is within a mile on the left, although that may not be where the meeting
is held.
I suggest getting there the night before the meeting (Sept 19.).
Bring warm clothes for the evenings - it drops into the 50's every night.
Also, be prepared to eat a lot of seafood.
-rpg-
∂19-Aug-84 1441 RPG Common Lisp meeting
∂17-Aug-84 1122 Moon@SCRC-QUABBIN.ARPA Common Lisp meeting
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 11:21:43 PDT
Received: from SCRC-YUKON by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 72399; Fri 17-Aug-84 14:20:46-EDT
Received: from SCRC-EUPHRATES by SCRC-YUKON via CHAOS with CHAOS-MAIL id 55472; Fri 17-Aug-84 14:20:46-EDT
Date: Fri, 17 Aug 84 14:20 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Common Lisp meeting
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: steele%tartan@CMU-CS-C.ARPA, dlw@SCRC-QUABBIN.ARPA, rpg@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12040198655.BABYL@CMU-CS-C.ARPA>
Message-ID: <840817142025.3.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri, 17 Aug 1984 13:06 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
I've just been talking with Ohlander, and he is going ahead with the
Common Lisp planning meeting in Monterey on Sept 18 and 19, despite my
protests that this is not enough notice for so large a meeting. I just
wanted to let you all know that this is still going to happen, and see
if all of us in the quiqewhatever can make it. It's an incredible pain
for me, but I've managed to juggle things arond so that I can get there.
It's also difficult for me, as I mentioned to Gabriel when he told me about this
meeting. I'll try to make it though.
By the way I have received no official notice of this meeting. I might still not
know about it at all if I hadn't happened to run into Gabriel in the Symbolics
lunch room a few weeks ago. Whose chains does Ohlander think he can pull?
∂19-Aug-84 1445 RPG More people
∂17-Aug-84 1503 DLW@SCRC-STONY-BROOK.ARPA More people
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 15:03:13 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 73922; Fri 17-Aug-84 18:02:09-EDT
Date: Fri, 17 Aug 84 18:01 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: More people
To: RPG@SU-AI.ARPA
In-Reply-To: The message of 17 Aug 84 14:42-EDT from Dick Gabriel <RPG at SU-AI>
Message-ID: <840817180154.8.DLW@CHICOPEE.SCRC.Symbolics>
Date: 17 Aug 84 1142 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
Could you send me the mailing addresses for HIC and Bernie? I want to specifically
invite them to the Monterey thing, especially Howard.
-rpg-
HIC at SCRC-Riverside and BSG at SCRC-Riverside.
Also, Jim Spoerl (our software marketing person) told me that he and
Tony Schofield (you know him, manager of marketing development) would
like to attend as well. I already told him to get in touch with you.
Their addresses are "spoerl at scrc-riverside" and "tony at
scrc-riverside".
∂19-Aug-84 1445 RPG DARPA
∂17-Aug-84 1506 DLW@SCRC-STONY-BROOK.ARPA DARPA
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 17 Aug 84 15:05:54 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 73928; Fri 17-Aug-84 18:05:25-EDT
Date: Fri, 17 Aug 84 18:05 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: DARPA
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA
In-Reply-To: The message of 17 Aug 84 14:43-EDT from Dick Gabriel <RPG at SU-AI>
Message-ID: <840817180510.9.DLW@CHICOPEE.SCRC.Symbolics>
I also would have preferred delaying the meeting somewhat, but I can
make it.
Does Ohlander know enough about Lisp that he would understand the
implications of proposed manual changes? Perhaps he feels that the main
thing that's needed is a vote-counter who will be perceived as impartial
by the outside world. I'm a little uncomfortable about Ohlander, partly
because I don't know him, but probably anybody who I do know would not
be considered impartial, as seen by an outsider. The fact that he's
from the military makes me wonder how well he'll be able to deal with
our highly informal style, but again since I don't know him, I can't tell
whether this is likely to be a problem or not.
∂19-Aug-84 1447 RPG Re:
∂18-Aug-84 1011 masinter.pa@Xerox.ARPA Re:
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 18 Aug 84 10:10:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 AUG 84 10:11:16 PDT
From: masinter.pa@XEROX.ARPA
Date: 18 Aug 84 10:11:02 PDT
Subject: Re:
In-reply-to: Your message of 18 Aug 84 08:33 PDT
To: Dick Gabriel <RPG@SU-AI.ARPA>
cc: masinter.pa@XEROX.ARPA
Thanks for the additional info... I'd still like an official "name and
purpose of meeting"... I presume from your messages that this is a
meeting about common lisp, but is it a meeting of "the common lisp
committee" or just for information? If there are votes taken, do I get a
vote? etc.
For the record, Dave Dyer works for Symbolics, if you want a rep from
ISI you should get someone else.
The official name is:
``DARPA Common Lisp Meeting''
The meeting is being sponsored by DARPA (Squires and Ohlander, specifically).
I believe that they will discuss DARPA's policies regarding Common Lisp. Some
technical issues will be aired, but I presume that the CL Big 5 will make most
of those decisions. An Executive Committee will be formed, which will probably
be the Big 5 and Ohlander as chairman.
Here is what Ohlander said about it most recently:
It is also important that the world gets informed on what DARPA's plans
and policies are. I don't want to delay in making this known. As you may
or may not know, some companies are making waves about supporting Common
Lisp, which is OK with me. The problem is that they object to us levying
CL as a standard. I want to nip these problems in the bud and take a
position that will be hard for us to back down from.
It is important that we have a public forum and general meeting so that
people cannot come back later and complain that they had no chance to
participate. Once we do this, I expect that a small number of people
will do the real work, as usual.
My specific goal in inviting you (and Xerox) is to be sure that you (and Xerox)
cannot claim to be left out of this meeting. You (and Xerox) will receive a
written invitation any day now, from DARPA.
-rpg-
∂20-Aug-84 1139 sjk@sri-spam mailing list
Received: from SRI-SPAM.ARPA by SU-AI.ARPA with TCP; 20 Aug 84 11:39:20 PDT
Received: by sri-spam.ARPA (4.22/4.16)
id AA20096; Mon, 20 Aug 84 11:38:17 pdt
Date: Mon, 20 Aug 84 11:38:17 pdt
From: Scott J. Kramer <sjk@sri-spam>
Message-Id: <8408201838.AA20096@sri-spam.ARPA>
Reply-To: sjk@sri-spam
To: common-lisp@su-ai
Subject: mailing list
Can you please add "common-lisp@sri-spam" to your mailing list? Thanx!
scott
∂20-Aug-84 2027 WVANROGGEN@DEC-MARLBORO.ARPA Re: Requests for clarification
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 20 Aug 84 20:27:10 PDT
Date: Mon 20 Aug 84 23:26:55-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: Requests for clarification
To: RAM@CMU-CS-C.ARPA
cc: STEELE@TL-20A.ARPA, common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of Sat 18 Aug 84 19:25:45-EDT
In general CLOSE should not close the component streams of a multiple
stream. A typical case I've run across is when one briefly creates
a broadcast stream that includes the terminal and a file. When the
broadcast stream is closed, the component streams do not want to be
closed, since they are likely to have uses beyond that of the broadcast
stream.
What's needed here is a function that takes a stream and returns a
list of component streams (if any).
---Walter
-------
∂21-Aug-84 1030 STEELE@TL-20A.ARPA Strange encounter on the Indiana Tollway
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 10:25:02 PDT
Received: ID <STEELE@TL-20A.ARPA>; Tue 21 Aug 84 13:20:49-EDT
Date: Tue 21 Aug 84 13:20:48-EDT
From: STEELE@TL-20A.ARPA
Subject: Strange encounter on the Indiana Tollway
To: common-lisp@SU-AI.ARPA, phw@MIT-MC.ARPA, bkph@MIT-MC.ARPA
At a rest stop on my way back from Chicago, I encountered an instance of yet
another shoot-the-robots video arcade game by Williams called "Robotron 2084".
Its idle (demo) mode included a lot of prose to set up the scenario as well as
the usual flashy pictures. The general idea is that the nasty robotrons are
out to kill all humans, and exactly one human family remains, consisting of
Mommy, Daddy, and Mikey. You are a superhuman genetic mutant capable of
shooting robots, and must save the last human family.
There are half a dozen types of robotrons, and lurid text in shifting colors
describes them in terms as titillating as possible while their abilities are
demonstrated pictorially. For example, the <GRUNT> ROBOTRONS attempt to
destroy you. The HULK ROBOTRONS seek out and eliminate the last human family.
The SPHEREOIDS [sic] and QUARKS manufacture ENFORCER and TANK ROBOTRONS. I
will now quote the last frame verbatim:
Beware the ingenious BRAIN ROBOTRONS which have the
power to reprogram humans into sinister PROGS!
--Guy
-------
∂21-Aug-84 1901 GS70@CMU-CS-A.ARPA From Frederking
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:01:29 PDT
Date: 21 Aug 84 2201 EDT (Tuesday)
From: Guy.Steele@CMU-CS-A.ARPA
To: common-lisp@SU-AI.ARPA
Subject: From Frederking
- - - - Begin forwarded message - - - -
Return-Path:<ref@cmu-cs-cad.arpa>
Received: from CMU-CS-CAD.ARPA by CMU-CS-A.ARPA; 20 Aug 84 14:14:32 EDT
Date: Monday, 20 August 1984 14:09:26 EDT
From: Robert.Frederking@cmu-cs-cad.arpa
To: guy.steele@cmu-cs-a.arpa
Subject: CommonLisp (vs. VaxLisp) question
Message-ID: <1984.8.20.18.1.32.Robert.Frederking@cmu-cs-cad.arpa>
Hi. I've been doing some programming in DEC VaxLisp, and have found
something annoying about the way they do structures. The way that the
automatically-defined type predicates work, you get an error if you pass
them nil. So, if you define a structure "ship", (ship-p nil) gives you an
error. What I was wondering was whether this is required by the CommonLisp
standard, or whether an implementor could allow nil to be the null structure.
I can't really tell from the CommonLisp manual.
The reason this is annoying is that I (and others) have a tendency
to write code so that nils pass through without being detected. Getting
errors when testing nils requires one either to screen for them, or write a
predicate that screens out nils and calls the built-in predicate (kind of
defeating its purpose). This has been the main problem in converting code
to use structures that originally used lists. Let me know what you think.
Thanks.
Bob
- - - - End forwarded message - - - -
∂21-Aug-84 1935 ALAN@MIT-MC From Frederking
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:34:57 PDT
Date: 21 August 1984 22:34-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: From Frederking
To: common-lisp @ SU-AI, Robert.Frederking @ CMU-CS-CAD
In-reply-to: Msg of 21 Aug 84 2201 EDT () from Guy.Steele at CMU-CS-A.ARPA
In my original defstruct implementation of the predicate feature I
naturally assumed that (SHIP-P NIL) would return NIL. It also seems quite
clear to me that the manual requires this to be the case. I would say DEC
VaxLisp defstruct has a bug.
∂21-Aug-84 1937 GS70@CMU-CS-A.ARPA Re: CommonLisp (vs. VaxLisp) question
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Aug 84 19:37:15 PDT
Date: 21 Aug 84 2236 EDT (Tuesday)
From: Guy.Steele@CMU-CS-A.ARPA
To: Robert.Frederking@cmu-cs-cad.arpa
Subject: Re: CommonLisp (vs. VaxLisp) question
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <1984.8.20.18.1.32.Robert.Frederking@cmu-cs-cad.arpa>
I have to agree that the manual needs clarification on the point
of the behavior of DEFSTRUCT-defined predicates. I would intrepret
the penultimate paragraph on page 306 as indicating by example that
any object whatsoever may be given to SHIP-P (and by extension to any
DEFSTRUCT-defined predicate). It would follow that the VaxLISP
implementation is at fault.
--Guy
∂23-Aug-84 0842 ref@cmu-cs-cad.arpa Painful retraction
Received: from CMU-CS-CAD.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 08:36:17 PDT
Date: Thursday, 23 August 1984 11:34:34 EDT
From: Robert.Frederking@cmu-cs-cad.arpa
To: guy.steele@cmu-cs-a.arpa
cc: common-lisp@su-ai.arpa, alan@mit-mc.arpa
Subject: Painful retraction
Message-ID: <1984.8.23.15.25.12.Robert.Frederking@cmu-cs-cad.arpa>
I made the mental equivalent of a typo in my original question to
Guy Steele, thus inadvertantly slandering DEC.
What I meant to inquire about was that the *access functions* give
fatal errors if handed nil, which is a more reasonable behavior (if still
personally annoying). Thus, (ship-name nil) blows up, whereas I would
prefer it to just return nil. I.e., it would be nice if nil were the "null
structure", even though structures aren't (in VaxLisp) implemented as lists.
So, I'll make a corrected version of my original question: would it
be against the CommonLisp standard for an implementor to allow nils to pass
through the automatically-defined access functions, even if structures are
not implemented as lists? (A much less exciting question, I'm afraid.)
Sorry for the confusion. (Blush.)
Bob
∂23-Aug-84 1104 FAHLMAN@CMU-CS-C.ARPA Painful retraction
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 11:04:13 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 23 Aug 84 13:57:11-EDT
Date: Thu, 23 Aug 1984 13:56 EDT
Message-ID: <FAHLMAN.12041780645.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Robert.Frederking@CMU-CS-CAD.ARPA
Cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA
Subject: Painful retraction
In-reply-to: Msg of 23 Aug 1984 11:34-EDT from Robert.Frederking at cmu-cs-cad.arpa
The access questions are another story. On stock hardware such as a
Vax, it is essential that (ship-captain foo) expand into something tense
like (svref foo 7), without supplying any helpful type-checking. IF the
access code is not as fast as the user could get by hand, users will
bypass the defstruct package altogether and revert to doing ugly things
by hand. So it is not reasonable on a machine like the Vax to have
(ship-captain nil) return nil and portable code should not depend on
this.
I don't think it would violate the standard for a particular
implementation to return nil in this case -- this sort of extension in a
situation that would otherwise be an error is generally allowed -- but I
would strongly advocate that no implementor do this without a very good
reason. Users of his system will come to depend on this trick,
sacrificing portability without realizing it.
-- Scott
∂23-Aug-84 1112 ALAN@MIT-MC Painful retraction
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 11:12:34 PDT
Date: 23 August 1984 14:10-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Painful retraction
To: Robert.Frederking @ CMU-CS-CAD
cc: common-lisp @ SU-AI, guy.steele @ CMU-CS-A
In-reply-to: Msg of 23 Aug 1984 11:34:34 EDT from Robert.Frederking at cmu-cs-cad.arpa
Date: Thursday, 23 August 1984 11:34:34 EDT
From: Robert.Frederking at cmu-cs-cad
I made the mental equivalent of a typo in my original question to
Guy Steele, thus inadvertantly slandering DEC.
I am in the habit of calling this a "thinko" or a "braino".
What I meant to inquire about was that the *access functions* give
fatal errors if handed nil, which is a more reasonable behavior (if
still personally annoying)....
I would oppose contracting access functions to any kind of behavior when
not handed an actual instance of the structure. In some mail that just
arrived this instant, I see that Fahlman has spared me the trouble of
giving the arguments against it here.
∂23-Aug-84 1433 WVANROGGEN@DEC-MARLBORO.ARPA structure references
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 14:33:42 PDT
Date: Thu 23 Aug 84 17:34:25-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: structure references
To: Robert.Frederking@CMU-CS-CAD.ARPA
cc: common-lisp@SU-AI.ARPA
With the proper declarations, something like SHIP-LENGTH does turn
into one VAX instruction, and for speed cannot check for illegal
or unusual arguments. Normally though it only checks that the
arguments are structures (or simple-vectors). It would have checked
that the type was correct, but since the type slot of a structure
might only be a subtype of the type assumed in the reference, it
would have had to do a SUBTYPEP (or the equivalent).
---Walter
-------
∂23-Aug-84 1756 JonL.pa@Xerox.ARPA Re: Painful retraction
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 17:56:25 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 84 17:54:30 PDT
Date: 23 Aug 84 17:51 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Painful retraction
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
Thu, 23 Aug 84 13:56 EDT
To: Fahlman@CMU-CS-C.ARPA
cc: Robert.Frederking@CMU-CS-CAD.ARPA, alan@MIT-MC.ARPA,
common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA
Your arguments about not wanting to do in-line type checking on stock
hardware are valid in general, but one could probably special-case the
NIL case without much loss. E.g. (ship-captain NIL) ==> exception
handling. The real question is, would it be worth it just for NIL.
If one implementation did it, there would be the strong temptation to
write non-portable code, i.e., depending on (ship-captain NIL) ==> NIL,
and such code couldn't be mechanically fixed. In view of this, either
the standard should permit this exception case, or we should lobby hard
to prevent it from being implemented in Common Lisp "dialects".
-- JonL --
∂23-Aug-84 1935 GS70@CMU-CS-A.ARPA Retraction
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 23 Aug 84 19:35:05 PDT
Date: 23 Aug 84 2234 EDT (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: frederking@CMU-CS-CAD.ARPA
Subject: Retraction
CC: common-lisp@SU-AI.ARPA
Well, the others on this mailing list have provided various rationales
for what *should* be the case. I will speak to the slightly different
question of what *is* the case, which fortunately results in the same
answer this time.
I interpret the text explaining the ship example on page 306 of the
Common LISP Manual as explicitly indicating that ship-x-position must
have a ship as its argument. The manual fails to state the obvious
generalization of thislater on (this is a general weakness of the
way this chapter is organized, for which I am sorry). Nevertheless,
I draw the indirect inference that a structure access function must
receive an argument that is the type of structure for which it was defined,
and anything else is an error. This means (page 5) that an implementation
may do anything it chooses if a structure acess function is given a NIL,
including returning NIL (though an error message is recommended),
but no valid Common LISP program may depend on any particular behavior
resulting from this situation. In practical terms, if you write
code that depends on (ship-x-position nil) => nil, it will not be
guaranteed portable.
--Guy
∂24-Aug-84 0930 Moon@SCRC-QUABBIN.ARPA Painful retraction
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 09:30:24 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 74613; Thu 23-Aug-84 14:31:44-EDT
Date: Thu, 23 Aug 84 14:32 EDT
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Painful retraction
To: Robert.Frederking@CMU-CS-CAD.ARPA
cc: guy.steele@CMU-CS-A.ARPA, common-lisp@SU-AI.ARPA, alan@MIT-MC.ARPA
In-Reply-To: <1984.8.23.15.25.12.Robert.Frederking@cmu-cs-cad.arpa>
Message-ID: <840823143232.2.MOON@EUPHRATES.SCRC.Symbolics>
Date: Thursday, 23 August 1984 11:34:34 EDT
From: Robert.Frederking@cmu-cs-cad.arpa
I made the mental equivalent of a typo in my original question to
Guy Steele, thus inadvertantly slandering DEC.
What I meant to inquire about was that the *access functions* give
fatal errors if handed nil, which is a more reasonable behavior (if still
personally annoying). Thus, (ship-name nil) blows up, whereas I would
prefer it to just return nil. I.e., it would be nice if nil were the "null
structure", even though structures aren't (in VaxLisp) implemented as lists.
So, I'll make a corrected version of my original question: would it
be against the CommonLisp standard for an implementor to allow nils to pass
through the automatically-defined access functions, even if structures are
not implemented as lists? (A much less exciting question, I'm afraid.)
Sounds like a bad idea to me. And why single out NIL?
If this were done, it certainly should be an option to DEFSTRUCT that is not
turned on by default, because only specialized applications would want it, and
everyone else would prefer not to lose the error-checking.
∂24-Aug-84 1003 CWH@SCRC-QUABBIN.ARPA Type-checking structure references
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 10:02:55 PDT
Received: from SCRC-YANGTZE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 74827; Thu 23-Aug-84 22:29:24-EDT
Date: Thu, 23 Aug 84 22:30 EDT
From: Carl Hoffman <CWH@SCRC-QUABBIN.ARPA>
Subject: Type-checking structure references
To: Robert.Frederking@CMU-CS-CAD.ARPA
cc: Alan@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA, Guy.Steele@CMU-CS-A.ARPA
In-Reply-To: <FAHLMAN.12041780645.BABYL@CMU-CS-C.ARPA>
Message-ID: <840823223017.2.CWH@YANGTZE.SCRC.Symbolics>
Alan Bawden's version of defstruct has a feature whereby you can define new
types from which to build structures, which can then be used as arguments to
the defstruct :type option. You do this by telling defstruct how to
construct, read from, and store into these types. So you could define your
own defstruct type in which (ship-captain foo) turned into
(if (null foo) nil (svref foo 7)) or whatever. Unfortunately, the defstruct
:type option in Common Lisp is not extensible.
∂24-Aug-84 1529 BSG@SCRC-RIVERSIDE.ARPA Painful retraction
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 15:28:41 PDT
Received: from SCRC-CONCORD by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 21266; Thu 23-Aug-84 15:04:22-EDT
Date: Thu, 23 Aug 84 15:04 EDT
From: "Bernard S. Greenberg" <BSG@SCRC-QUABBIN.ARPA>
Subject: Painful retraction
To: Fahlman@CMU-CS-C.ARPA, Robert.Frederking@CMU-CS-CAD.ARPA
cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA
In-Reply-To: <FAHLMAN.12041780645.BABYL@CMU-CS-C.ARPA>
Message-ID: <840823150432.6.BSG@CONCORD.SCRC.Symbolics>
Date: Thu, 23 Aug 1984 13:56 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
I don't think it would violate the standard for a particular
implementation to return nil in this case -- this sort of extension in a
situation that would otherwise be an error is generally allowed -- but I
would strongly advocate that no implementor do this without a very good
reason. Users of his system will come to depend on this trick,
sacrificing portability without realizing it.
I don't see any justification for such an extension. Extend CDR to take
the successor of a number... how is that different? NIL is clearly not
defined to be "a member of all data types" or similar. I think the
proposed extension violates the spirit of Lisp.
What do you (Scott) think are similar situations "that would otherwise
be an error" that are really parallel?
∂25-Aug-84 0620 FAHLMAN@CMU-CS-C.ARPA Painful retraction
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Aug 84 06:20:42 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 25 Aug 84 09:15:04-EDT
Date: Sat, 25 Aug 1984 09:15 EDT
Message-ID: <FAHLMAN.12042253658.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG@SCRC-QUABBIN.ARPA>
Cc: alan@MIT-MC.ARPA, common-lisp@SU-AI.ARPA, guy.steele@CMU-CS-A.ARPA,
Robert.Frederking@CMU-CS-CAD.ARPA
Subject: Painful retraction
In-reply-to: Msg of 23 Aug 1984 15:04-EDT from Bernard S. Greenberg <BSG at SCRC-QUABBIN.ARPA>
What do you (Scott) think are similar situations "that would otherwise
be an error" that are really parallel?
For example, those implementations that add a new Instance data type to
support flavors have to extend several of the basic operators to cover
this new type. Implementations that have extra I/O options must extend
the stream operators to take new keywords. Implemenations with new
number types (continued fractions, anyone?) have to overload the
arithmetic operators. And so on. It seems to me that the spirit of
Common Lisp says that everything legal according to the manual ought to
work in all implementations, and that the way you create a superset is
to make combinations that are otherwise undefined work in some
particular way.
So it seems to me that Frederking's extension is technically legal, in
that it wouldn't break any portable code and wouldn't fail to signal an
error in those cases that are specifically required to signal an error.
I also feel that it is unwise, because in the cases cited above it will
be very clear to users that they are delaing with entities or
combinations outside the base language, while users doing (SHIP-CAPTAIN
NIL) might imagine that they are still within the portable standard.
-- Scott
∂26-Aug-84 1315 RPG
∂24-Aug-84 1144 KMP@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Aug 84 11:42:33 PDT
Date: 24 August 1984 14:05-EDT
From: Kent M Pitman <KMP @ MIT-MC>
To: RPG @ SU-AI, Guy.Steele @ CMU-CS-A
There's a lisp being distributed for IBM PC's (I think) called
Gold Hill Common Lisp, or some such thing. It's got Winston's
lisp tutor thing running in it. The thing is, I was talking to
Winston the other day and he said that as far as he knew, it is
not really a Common Lisp. It just uses that name. It would be
nice if we could find out if that's true, and if it is, hassle
them about abuse of the name. Is CL trademarked, or could it be?
Some friends of mine looked it over at AAAI; it is definitely not
a Common Lisp. First of all, it is a dynamic Lisp. I'm not sure what
to do about it.
-rpg-
∂26-Aug-84 1841 DLW@SCRC-STONY-BROOK.ARPA Questions from M. Hagiya
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 26 Aug 84 18:40:58 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 79878; Sun 26-Aug-84 21:12:56-EDT
Date: Sun, 26 Aug 84 21:11 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions from M. Hagiya
To: common-lisp@SU-AI.ARPA
Message-ID: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics>
T. Yuasa and M. Hagiya of Kyoto University independently implemented
Common Lisp for the Data General MV/10000. They had a number of
questions about the definition of Common Lisp, which they accumulated in
a file. Hagiya presented me a hardcopy of this file when I visited them
in Kyoto last month. I answered some of the questions, but there were
others whose answer I either didn't know, or considered undefined. I
told Hagiya that I would pass these questions through to the other
Common Lisp designers, and that if there were an answer I would try to
get it back to him. I have paraphrased most of the questions, both to
correct the English and to clarity the intent (I discussed each question
with Hagiya). (His English isn't bad at all; he even got the "BOA
constructor" joke!)
First, the questions that I think might reflect problems or ambiguities
with the Common Lisp definition:
If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)),
does Common Lisp specify that this "works", i.e. that the symbol "moshi"
(a Japanese word for "if") can now be used as the name-symbol of a
special form, just as well as "if"? (I told him I thought the answer
was "no", but it's not stated clearly in the manual.)
In a defmacro argument list, (&whole w a b) presumably means that there
must be exactly two arguments to the macro, which a and b will be bound
to, and furthermore that w will be bound to the whole thing. By
extension, (&whole w a) means that there must be exactly one argument,
and so (&whole w) means that there must not be any arguments at all. If
so, then the (&whole w) case is evidently useless, and if what you
really want is to just have a macro that lets you examine the body
yourself and doesn't play with argument lists, you need to do (&whole w
&rest ignore) or something. Is this really the definition of Common
Lisp?
Is this an example of legal syntax: #c(0 #.pi)
What do equal and equalp do for structures? (The same question came up
on this mailing list recently. Hagiya asked "Are they obvious?", and
since he and I agreed what the obvious definition must be, I told him
yes. However, as we discussed, the manual doesn't tell.)
Suppose we redeclare a structure (evaluate defstruct for a structure
we've already defined), and a slot that had originally been declared
non-read-only is redeclared to be read-only. Should the access function
for that slot be deleted (fmakunbound'ed)?
Should the streams that are arguments to make-broadcast-stream,
make-concatenated-stream, or make-echo-stream be of the same element
type?
What is the element type of "bit sink" (that is, make-broadcast-stream
of no arguments)? (I told him that T seemed right to me, but agreed
that the point needs clarification.) Also, what is the element type of
a concatenated stream made of no streams? (I'm not sure it matters.)
If the reader sees a close-paren at top-level, must this signal an
error, may it be ignored, or what?
If only line-by-line I/O is supported, may the function "print" do a
terpri after printing a form rather than before? (I am not completely
sure what he means here, but I think the point was that the DG operating
system is only allowing him to do line-at-a-time I/O, and the definition
of "print" was not completely implementable in this framework.)
While LOADing a file, what is the value of *standard-input*? (I told
him that I thought for a character file it really ought to be the file
stream, but the manual needs to say and doesn't. What should it be when
the file is binary?)
Now, in addition to these questions, he also had some particular
comments, and some questions that I had no trouble answering but might
indicate points at which the manual needs to be more explicit. The rest
of this message consists of these comments and points; I consider these
less important than the above, so if you're tired you can stop reading
at this point.
He feels that the algorithm to determine whether a type is a sub-type of
another is vague, and feels it should be spelled out more.
He says that it is specified that any structure is a sub-type of
"structure", but "structure" is not in Table 4-1. The latter is true
but I can't find where the former is stated.
In 17.4, the parameters are referred to as "bit-array", although the
data type specifier used in chapter 4 is "bit-vector". There is no
error here as far as I can see, but apparantly Hagiya found it
inconsistent.
Can a symbol be a function and a macro at the same time? (Of course I
told him no. His internal representation is actually sort of set up
to allow this, but of course the interpreter has to do exactly one thing
with a form, so actually his implementation doesn't do anything unusual.)
Recovery from a name conflict in packages seems to be
implementation-dependent. Can it be a fatal error? (Yes.)
Can the value of the parameter "package" for package functions be a
symbol or a string? (Yes, the manual is quite explicit about this.)
How about *package*? (It has to be a package object, as returned by
find-package. The manual is not particularly unclear, but might
emphasize this point.)
How do you implement "rationalize"? (I didn't know off hand. By the
way, this makes me suspect that these folks don't have a copy of the CMU
sources.)
He had some confusion about parsing after #\. I do think the manual
could be more explicit about the algorithm for deciding where the break
after seeing #\.
If the character set is ASCII, how do we represent ASCII control
characters? (Implementation dependent. Their implementation currently
uses #\↑A, and I told him that I thought other implementations probably
did exactly that as well.)
He was confused by the term "alphadigit" in Table 22-3, apparently not
having read the fine print at the bottom. I presume that the function
alpha-char-p needs to reference *read-base* in order to function properly?
What is the initial value of *default-pathname-defaults*? (Implementation
dependent; the manual should say so explicitly.)
They were also both quite confused about how to implement #,. I belive
that the problems they were having are based on the issues that were
discussed on this list recently. #, definitely needs better
explanation.
∂26-Aug-84 2025 WHOLEY@CMU-CS-C.ARPA Questions from M. Hagiya
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Aug 84 20:25:35 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sun 26 Aug 84 23:03:48-EDT
Date: Sun, 26 Aug 1984 23:03 EDT
Message-ID: <WHOLEY.12042666619.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Questions from M. Hagiya
Re: Questions from M. Hagiya
If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)),
does Common Lisp specify that this "works", i.e. that the symbol "moshi"
(a Japanese word for "if") can now be used as the name-symbol of a
special form, just as well as "if"? (I told him I thought the answer
was "no", but it's not stated clearly in the manual.)
The manual explicitly states (on page 90) that is is an error to invoke the
thing that symbol-function returns if macro-p or special-form-p of that symbol
is true. That seems lucid enough.
Is this an example of legal syntax: #c(0 #.pi)
I don't know if that's a legal complex number (the components are of different
types), but I believe it's just as easy (perhaps easier) to make a reader
accept #c(0.0l0 #.pi) instead of scream about it.
Should the streams that are arguments to make-broadcast-stream,
make-concatenated-stream, or make-echo-stream be of the same element
type?
I would say no. One can imagine that reading from a concatenated stream made
of different bytes sizes could be put to some good use.
What is the element type of "bit sink" (that is, make-broadcast-stream
of no arguments)? (I told him that T seemed right to me, but agreed
that the point needs clarification.) Also, what is the element type of
a concatenated stream made of no streams? (I'm not sure it matters.)
Using the AND'ing of types that Spice Lisp does, a Make-Broadcast-Stream of no
streams can be thought to have an element type of (AND), which simplifies to T.
AND of no arguments as a type specifier is not described, but interpreting the
identity of that type specifier to be T seems right.
If the reader sees a close-paren at top-level, must this signal an
error, may it be ignored, or what?
As a user, I would like to have this behavior on a switch. Spice Lisp ignores
them, but Zetalisp (and the CLCP) signal errors. I've found the Zetalisp
behavior generally annoying but sometimes helpful.
While LOADing a file, what is the value of *standard-input*? (I told
him that I thought for a character file it really ought to be the file
stream, but the manual needs to say and doesn't. What should it be when
the file is binary?)
I don't think anything should happen to *Standard-Input*. Consider a program
(i.e. a file of Lisp code) that wants to query the user when it is loaded. In
that case, leaving *Standard-Input* as is is useful. I can't think of any
useful thing one could do with having *Standard-Input* be bound to the file.
Can a symbol be a function and a macro at the same time? (Of course I
told him no. His internal representation is actually sort of set up
to allow this, but of course the interpreter has to do exactly one thing
with a form, so actually his implementation doesn't do anything unusual.)
Allowing a symbol to be both a special form and a macro is useful however, so
that things can be interepreted quickly and a portable code-analyzer can pick
them apart.
How do you implement "rationalize"? (I didn't know off hand. By the
way, this makes me suspect that these folks don't have a copy of the CMU
sources.)
Perhaps they didn't dig far enough into SPNUM, which has other things like
lisp-level code for bignum arithmetic that wouldn't necessarily interest
other implementors. It's there, preceded by this comment:
;;; Thanks to Kim Fateman, who stole this function rationalize-float
;;; from macsyma's rational. Macsyma'a rationalize was written
;;; by the legendary Gosper (rwg). Gosper is now working for xerox
;;; at parc. Guy Steele said about Gosper, "He has been called the
;;; only living 17th century mathematician and is also the best
;;; pdp-10 hacker I know." So, if you can understand or debug this
;;; code you win big.
He was confused by the term "alphadigit" in Table 22-3, apparently not
having read the fine print at the bottom. I presume that the function
alpha-char-p needs to reference *read-base* in order to function properly?
No. The definition of Alpha-Char-P is straightforward enough. At the end:
"Of the standard characters, the letters A through Z and
a though z are alphabetic."
I don't see at all how frobbing *Read-Base* can change this.
∂27-Aug-84 0558 @MIT-MC:Cassels@SCRC-QUABBIN Questions from M. Hagiya
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 05:57:54 PDT
Received: from SCRC-CUYAHOGA by WAIKATO via CHAOS with CHAOS-MAIL id 48137; Mon 27-Aug-84 08:57:31-EDT
Date: Mon, 27 Aug 84 08:57 EDT
From: "Robert A. Cassels" <Cassels@SCRC-QUABBIN.ARPA>
Subject: Questions from M. Hagiya
To: DLW@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
In-Reply-To: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics>
Message-ID: <840827085735.2.CASSELS@CUYAHOGA.SCRC.Symbolics>
Date: Sun, 26 Aug 84 21:11 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
T. Yuasa and M. Hagiya of Kyoto University independently implemented
Common Lisp for the Data General MV/10000. They had a number of
questions about the definition of Common Lisp, ....
How do you implement "rationalize"? (I didn't know off hand. By the
way, this makes me suspect that these folks don't have a copy of the CMU
sources.)
Send them each a copy of Bill Gosper's continued-fractions paper.
∂27-Aug-84 0627 @MIT-MC:mly@MIT-MC Questions from M. Hagiya
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 06:27:02 PDT
Received: from MIT-LISPM-25 by MIT-OZ via Chaosnet; 27 Aug 84 09:25-EDT
To: common-lisp at SU-AI.ARPA
Subject: Questions from M. Hagiya
From: Pinhead <mly@mit-mc.arpa>
Date: Mon, 27 Aug 84 09:23 EDT
Message-ID: [Yow-259]
Date: Mon, 27 Aug 84 08:57 EDT
From: Robert A. Cassels <Cassels at SCRC-QUABBIN.ARPA>
To: DLW at SCRC-QUABBIN.ARPA, common-lisp at SU-AI.ARPA
Re: Questions from M. Hagiya
Date: Sun, 26 Aug 84 21:11 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
T. Yuasa and M. Hagiya of Kyoto University independently implemented
Common Lisp for the Data General MV/10000. They had a number of
questions about the definition of Common Lisp, ....
How do you implement "rationalize"? (I didn't know off hand. By the
way, this makes me suspect that these folks don't have a copy of the CMU
sources.)
Send them each a copy of Bill Gosper's continued-fractions paper.
Send them DEFECTIVE LIFESTYLE ACCESTORIES in PLAID SAMSONITE steamer trunks!
∂27-Aug-84 0640 DLW@SCRC-RIVERSIDE.ARPA Questions from M. Hagiya
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 06:39:58 PDT
Received: from SCRC-CHICOPEE by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 21540; Mon 27-Aug-84 09:40:07-EDT
Date: Mon, 27 Aug 84 09:40 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: Questions from M. Hagiya
To: Wholey@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12042666619.BABYL@CMU-CS-C.ARPA>
Message-ID: <840827094009.0.DLW@CHICOPEE.SCRC.Symbolics>
Date: Sun, 26 Aug 1984 23:03 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
The manual explicitly states (on page 90) that is is an error to invoke the
thing that symbol-function returns if macro-p or special-form-p of that symbol
is true. That seems lucid enough.
No, I don't think that has anything to do with it. The thing returned
is not a function, but that doesn't mean that you can't stick it back
into a symbol and use that symbol as the name of a special form.
I don't know if that's a legal complex number (the components are of different
types), but I believe it's just as easy (perhaps easier) to make a reader
accept #c(0.0l0 #.pi) instead of scream about it.
Whether it's easy to make the reader do it wasn't the question, though.
The question is one of language definition. I strongly suspect that all
of the existing Common Lisp readers will accept that definition, since
they probably use READ to parse after #c.
I don't think anything should happen to *Standard-Input*. Consider a program
(i.e. a file of Lisp code) that wants to query the user when it is loaded. In
that case, leaving *Standard-Input* as is is useful. I can't think of any
useful thing one could do with having *Standard-Input* be bound to the file.
In Maclisp, it was quite standard to put (read) into a file in order to
get the next form and manipulate it. The main motivation for doing that
has been eliminated by the introduction of eval-when, but Maclisp
programmers certainly expect (read) in a file to read from the file. I
don't feel strongly either way, but it really should be specified.
Would you please mail me, under separate cover, the Spice Lisp
definition of "rationalize", if that's OK? Thanks. By the way, Gosper
hasn't been working for PARC for some time; he works for Symbolics
currently.
He was confused by the term "alphadigit" in Table 22-3, apparently not
having read the fine print at the bottom. I presume that the function
alpha-char-p needs to reference *read-base* in order to function properly?
No. The definition of Alpha-Char-P is straightforward enough. At the end:
"Of the standard characters, the letters A through Z and
a though z are alphabetic."
I don't see at all how frobbing *Read-Base* can change this.
Aha, now I remember. The real problem Hagiya was having is that
alpha-char-p uses the term "alphabetic" one way, and Table 22-3 uses it
a completely different way. This really needs to be fixed.
∂27-Aug-84 0746 WHOLEY@CMU-CS-C.ARPA Rationalize
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 07:45:31 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 27 Aug 84 10:36:39-EDT
Date: Mon, 27 Aug 1984 10:36 EDT
Message-ID: <WHOLEY.12042792787.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Rationalize
Sorry for broadcasting incorrect information about Gosper's place of employment
-- the comment and the code below were written long ago. I found the comment
while looking for the code and thought it amusing. So this isn't Info-Cobol.
I believe the only piece of non-portability in it is the assumption that there
are only two types of floats.
(defun rationalize (x)
(typecase x
(rational x)
(short-float (rationalize-float x short-float-epsilon))
(long-float (rationalize-float x long-float-epsilon))
(otherwise (error "~A is not a non-complex number" x))))
(defun rationalize-float (x eps)
(cond ((minusp x) (- (rationalize (- x))))
((zerop x) 0)
(t (let ((y ())
(a ()))
(do ((xx x (setq y (/ 1.0s0
(- xx (float a x)))))
(num (setq a (truncate x))
(+ (* (setq a (truncate y)) num) onum))
(den 1 (+ (* a den) oden))
(onum 1 num)
(oden 0 den))
((and (not (zerop den))
(not (> (abs (/ (- x (/ (float num x)
(float den x)))
x))
eps)))
(/ num den)))))))
∂27-Aug-84 1245 Moon@SCRC-QUABBIN.ARPA Questions from M. Hagiya
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 12:44:29 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76082; Mon 27-Aug-84 15:41:35-EDT
Date: Mon, 27 Aug 84 15:43 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Questions from M. Hagiya
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>, common-lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12042666619.BABYL@CMU-CS-C.ARPA>
Message-ID: <840827154344.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sun, 26 Aug 1984 23:03 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Re: Questions from M. Hagiya
While LOADing a file, what is the value of *standard-input*? (I told
him that I thought for a character file it really ought to be the file
stream, but the manual needs to say and doesn't. What should it be when
the file is binary?)
I don't think anything should happen to *Standard-Input*. Consider a program
(i.e. a file of Lisp code) that wants to query the user when it is loaded. In
that case, leaving *Standard-Input* as is is useful. I can't think of any
useful thing one could do with having *Standard-Input* be bound to the file.
Users must be queried over *query-io*, not *standard-input*.
∂27-Aug-84 1301 Moon@SCRC-QUABBIN.ARPA Rationalize
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 13:01:15 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76086; Mon 27-Aug-84 15:47:03-EDT
Date: Mon, 27 Aug 84 15:49 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Rationalize
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12042792787.BABYL@CMU-CS-C.ARPA>
Message-ID: <840827154913.8.MOON@EUPHRATES.SCRC.Symbolics>
Hmm, that definition of rationalize is completely different from ours, which
was also written by Gosper but is not completely implementation-independent.
Are you sure yours satisfies the axiom (float (rationalize x) x) = x? Am I
sure ours does? Does anybody have a test suite for rationalize?
∂27-Aug-84 2045 RZ@MIT-MC Rationalize
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 27 Aug 84 20:45:39 PDT
Date: 27 August 1984 23:45-EDT
From: Richard E. Zippel <RZ @ MIT-MC>
Subject: Rationalize
To: Wholey @ CMU-CS-C
cc: Common-Lisp @ SU-AI, DLW @ SCRC-QUABBIN, RWG @ SCRC-STONY-BROOK
I thought I'd put my two cents since I had something to do with this stuff.
First, unless my memory is massively wrong, I was the one whoe first
implemented rationalize in Macsyma. I believe it was Bill Gosper that
requested it. Bill correct me if I'm wrong.
Second, while I have your attention let me explain the algorithm since it is
really quite simple. All positive real numbers can be represented as a
continued fraction, viz.
alpha = a0 + 1/(a1 + 1/(a2 + ... 1/an) ... )
If alpha is not a rational number then the continued fraction does not
terminate. Initial segments of the continued fraction lead to the best
rational approximations to alpha. (This is proven in any book on elementary
number theory.)
The algorithm in rationalize consists of two parts that are melded together.
First, one computes the sequence of partial quotients: a0, a1, a2, ...
and then use them to compute rational approximations to alpha.
The ai are easy to calculate, a0 is the floor (truncate) of alpha,
a1 is the floor of 1/(alpha-a0), etc. Let alpha[0] = alpha, a0 =
truncate(alpha[0]) and alpha[i] = 1/(alpha(i-1) - ai) then
ai = truncate(alpha(i)).
Computing the rational approximation is a little more complicated.
Let p[0]/q[0] = a0/1, p[1]/q[1] = a0 + 1/a1, etc. (the rational
approximations to alpha). Also let p[-1] = 0, q[-1] = 1.
Then p[i] = ai p[i-1] + p[i-2]
q[i] = ai q[i-1] + q[i-2].
It is also useful to know that each pair of p[i] and q[i] is relatively
prime.
The code given by Skef, intertwines the two phases of this algorithm to
avoid consing or using the stack. Remember it was originally implemented
for Macsyma which was terribly short on space.
∂28-Aug-84 0815 DLW@SCRC-QUABBIN.ARPA Rationalize
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 28 Aug 84 08:15:39 PDT
Received: from SCRC-CHICOPEE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 76345; Tue 28-Aug-84 10:20:57-EDT
Date: Tue, 28 Aug 84 10:23 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: Rationalize
To: Wholey@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <WHOLEY.12042792787.BABYL@CMU-CS-C.ARPA>
Message-ID: <840828102337.8.DLW@CHICOPEE.SCRC.Symbolics>
Just as another spot-check of portability, I tried out the slisp
definition of "rationalize" in the Symbolics CLCP, and it works.
However, on some hard cases (cases with large numerators and
denominators), it gets different answers than ours. For example, both
functions, given 1.6666666, return 5/3. However, if you lop off one 6
and try 1.666666, ours gets 798918/479351 whereas yours gets
873813/524288. In octal, that's 3030306/1650167 for ours and
3252525\2000000 for yours, which may be more revealing. Anyway, doing
the divisions back, using double precision, ours gives
1.666666030883789d0 (3.088d0 error), and yours gives 1.666659712820042d0
(2.872d0 error). I'm not sure what the significance [I know] of this is.
∂28-Aug-84 1215 Cassels@SCRC-STONY-BROOK.ARPA Rationalize
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 28 Aug 84 12:14:38 PDT
Received: from SCRC-CUYAHOGA by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 81147; Tue 28-Aug-84 15:10:23-EDT
Date: Tue, 28 Aug 84 15:10 EDT
From: "Robert A. Cassels" <Cassels@SCRC-QUABBIN.ARPA>
Subject: Rationalize
To: DLW@SCRC-QUABBIN.ARPA, Wholey@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <840828102337.8.DLW@CHICOPEE.SCRC.Symbolics>
Message-ID: <840828151023.3.CASSELS@CUYAHOGA.SCRC.Symbolics>
Date: Tue, 28 Aug 84 10:23 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Just as another spot-check of portability, I tried out the slisp
definition of "rationalize" in the Symbolics CLCP, and it works.
However, on some hard cases (cases with large numerators and
denominators), it gets different answers than ours. For example, both
functions, given 1.6666666, return 5/3. However, if you lop off one 6
and try 1.666666, ours gets 798918/479351 whereas yours gets
873813/524288. In octal, that's 3030306/1650167 for ours and
3252525\2000000 for yours, which may be more revealing. Anyway, doing
the divisions back, using double precision, ours gives
1.666666030883789d0 (3.088d0 error), and yours gives 1.666659712820042d0
(2.872d0 error). I'm not sure what the significance [I know] of this is.
Either is acceptable to CL:
"[RATIONALIZE] ... may return any rational number for which the
floating-point number is the best available approximation of its format;
... it attempts to keep both numerator and denominator small."
Ours is defined to be the fraction of smallest denominator which lies in
the "floating-point interval" around the argument. It is definitely not
the most accurate. But of course the most accurate rational
approximation to a floating-point number F is (RATIONAL F). Ours
derives from RWG's paper on continued fractions wherein he shows how to
solve such important questions as, "If a baseball player is hitting
.319, what is the smallest number of at-bats he could have had?"
So we subscribe to the view that, "... RATIONALIZE goes to more trouble
to produce a result that is more pleasant to view ...". You'll have to
decide for yourself whether 798918/479351 is more pleasant than
873813/524288.
∂29-Aug-84 2011 Moon@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Aug 84 20:08:15 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 82003; Wed 29-Aug-84 22:54:19-EDT
Date: Wed, 29 Aug 84 22:53 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: (defmacro foo (&whole w) ...)
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <840826211121.0.DLW@CHICOPEE.SCRC.Symbolics>
Message-ID: <840829225336.4.MOON@EUPHRATES.SCRC.Symbolics>
Date: Sun, 26 Aug 84 21:11 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
T. Yuasa and M. Hagiya of Kyoto University independently implemented
Common Lisp for the Data General MV/10000. They had a number of
questions about the definition of Common Lisp, which they accumulated in
a file....
In a defmacro argument list, (&whole w a b) presumably means that there
must be exactly two arguments to the macro, which a and b will be bound
to, and furthermore that w will be bound to the whole thing. By
extension, (&whole w a) means that there must be exactly one argument,
and so (&whole w) means that there must not be any arguments at all. If
so, then the (&whole w) case is evidently useless, and if what you
really want is to just have a macro that lets you examine the body
yourself and doesn't play with argument lists, you need to do (&whole w
&rest ignore) or something. Is this really the definition of Common
Lisp?
Due to a bug in our implementation, neither (defmacro foo (&whole w) ...)
nor (defmacro foo () ...) checked the number of subforms, although all other
cases of defmacro did. I decided that this was actually a feature in the
&whole case, so when I fixed the bug I made the &whole case be treated
specially and not check the number of subforms. This is certainly a
wart, but it makes life easier for the user and I can't see how it hurts
anything. In particular, I have some places where I want to depend on
this myself. [By the way, the bug is only fixed in my private copy of
defmacro currently.]
I propose these rules for inclusion in the language:
(defmacro foo () ...) requires that invocations of foo have no subforms.
(defmacro foo (&whole w) ...), as a special case, allows any number of subforms.
(defmacro foo (&whole w a) ...) requires that invocations of foo have exactly one subform.
Opinions?
∂30-Aug-84 0644 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 30 Aug 84 06:44:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 30 Aug 84 09:42:26-EDT
Date: Thu, 30 Aug 1984 09:42 EDT
Message-ID: <FAHLMAN.12043569344.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: (defmacro foo (&whole w) ...)
In-reply-to: Msg of 29 Aug 1984 22:53-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
In the current Spice Lisp implementation, &whole sets the same switch
that &rest does. This leaves too-few-arguments checking in place, but
disables too-many-arguments checking. So if there is an &whole anywhere
in the arglist, you have to supply at least enough subforms to satisfy
the required arguments (if any), but you are free to supply extras which
the user can access by picking apart the &whole argument by hand. This
seems intuitively right to me; it would be confusing to require &whole
and &rest in the same arglist or to special-case the situation where
&whole appears alone.
This would give the same results as proposed by Moon, but
(defmacro foo (&whole w a) ...)
would require AT LEAST one subform, not EXACTLY one subform.
-- Scott
∂30-Aug-84 1344 Moon@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 30 Aug 84 13:44:00 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 82391; Thu 30-Aug-84 16:44:36-EDT
Date: Thu, 30 Aug 84 16:43 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: (defmacro foo (&whole w) ...)
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12043569344.BABYL@CMU-CS-C.ARPA>
Message-ID: <840830164339.6.MOON@EUPHRATES.SCRC.Symbolics>
Date: Thu, 30 Aug 1984 09:42 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
In the current Spice Lisp implementation, &whole sets the same switch
that &rest does. This leaves too-few-arguments checking in place, but
disables too-many-arguments checking. So if there is an &whole anywhere
in the arglist, you have to supply at least enough subforms to satisfy
the required arguments (if any), but you are free to supply extras which
the user can access by picking apart the &whole argument by hand. This
seems intuitively right to me; it would be confusing to require &whole
and &rest in the same arglist or to special-case the situation where
&whole appears alone.
This would give the same results as proposed by Moon, but
(defmacro foo (&whole w a) ...)
would require AT LEAST one subform, not EXACTLY one subform.
It would be okay by me if the language were defined to make this the standard
behavior.
∂31-Aug-84 1613 Moon@SCRC-STONY-BROOK.ARPA documentation strings
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 84 16:12:45 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83063; Fri 31-Aug-84 16:49:14-EDT
Date: Fri, 31 Aug 84 16:47 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: documentation strings
To: Common-Lisp@SU-AI.ARPA
Message-ID: <840831164747.9.MOON@EUPHRATES.SCRC.Symbolics>
Macros may expand into declarations. May macros expand into documentation strings?
∂31-Aug-84 1727 Moon@SCRC-QUABBIN.ARPA applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 31 Aug 84 17:26:23 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 77493; Fri 31-Aug-84 20:21:38-EDT
Date: Fri, 31 Aug 84 20:24 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: applyhook
To: common-lisp@SU-AI.ARPA
Message-ID: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>
APPLYHOOK should not take an &OPTIONAL ENV argument.
Similarly *APPLYHOOK* should receive two arguments, not three arguments.
An environment is not meaningful for the APPLY operation, only for the EVAL operation.
Does anyone disagree?
∂01-Sep-84 1602 EAK@MIT-MC Questions from M. Hagiya
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 16:02:49 PDT
Date: 1 September 1984 19:03-EDT
From: Earl A. Killian <EAK @ MIT-MC>
Subject: Questions from M. Hagiya
To: DLW @ SCRC-QUABBIN
cc: common-lisp @ SU-AI
In-reply-to: Msg of Sun 26 Aug 84 21:11 EDT from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
Date: Sun, 26 Aug 84 21:11 EDT
From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)),
does Common Lisp specify that this "works", i.e. that the symbol "moshi"
(a Japanese word for "if") can now be used as the name-symbol of a
special form, just as well as "if"? (I told him I thought the answer
was "no", but it's not stated clearly in the manual.)
I would tend to agree withj your "no"; on the other hand I feel
strongly that there ought to be a *PORTABLE* way to do renaming.
Obviously having MOSHI be a synonym for IF can easily be done by
macros; the more interesting case is when you want to make MOSHI
mean IF and IF then mean something else. Unfortunately most
compilers seem to build the known function names right into the
compiler source (e.g. (EQ F '+)) rather than using a database
that can be rearranged (e.g. by using symbol property lists).
If something isn't done about this, then it is going to be
difficult to experiment with future language design using Common
Lisp implementations as a starting point.
∂01-Sep-84 1645 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@SU-AI Re: Questions from M. Hagiya
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 16:44:48 PDT
Date: 1 Sep 1984 1940-EDT
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@SU-AI>
Subject: Re: Questions from M. Hagiya
To: EAK%MIT-MC@SU-AI
cc: DLW%SCRC-QUABBIN%MIT-MC@SU-AI, common-lisp@SAIL
In-Reply-To: The message of 1 September 1984 19:03-EDT from Earl A. Killian <EAK @ MIT-MC>
Date: 1 September 1984 19:03-EDT
From: Earl A. Killian <EAK @ MIT-MC>
Date: Sun, 26 Aug 84 21:11 EDT
From: Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
If we evaluate (setf (symbol-function 'moshi) (symbol-function 'if)),
does Common Lisp specify that this "works", i.e. that the symbol "moshi"
(a Japanese word for "if") can now be used as the name-symbol of a
special form, just as well as "if"? (I told him I thought the answer
was "no", but it's not stated clearly in the manual.)
I would tend to agree withj your "no"; on the other hand I feel
strongly that there ought to be a *PORTABLE* way to do renaming.
Obviously having MOSHI be a synonym for IF can easily be done by
macros; the more interesting case is when you want to make MOSHI
mean IF and IF then mean something else. Unfortunately most
compilers seem to build the known function names right into the
compiler source (e.g. (EQ F '+)) rather than using a database
that can be rearranged (e.g. by using symbol property lists).
Not just the gut of the compiler that does (EQ F '+), but
macro packages and code-transformers inside and outside compilers
expect `(+ ,x ,y) or whatever to generate a reference to the +
that it knows about. If we follow your line (which is not without
merit), it will be extremely difficult, if not impossible,
to write macros that can be used with referential transparency
in systems where renaming is taking place.
-------
∂01-Sep-84 1845 FAHLMAN@CMU-CS-C.ARPA Questions from M. Hagiya
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 18:41:53 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 1 Sep 84 21:24:14-EDT
Date: Sat, 1 Sep 1984 21:24 EDT
Message-ID: <FAHLMAN.12044221405.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Earl A. Killian" <EAK@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Questions from M. Hagiya
In-reply-to: Msg of 1 Sep 1984 19:03-EDT from Earl A. Killian <EAK at MIT-MC>
Actually, the Spice Lisp compiler is driven almost entirely by modular
transforms and code-generation functions that live on the property list
of the form in question. The old Lisp Machine compiler was similar, and
I think that Symbolics, at least, has stuck with this style. However,
if you mess with really fundamental things like IF and QUOTE, you'll
confuse an awful lot of macros and transforms that generate these
expecting the old meaning to hold.
Maybe instead of messing around with Lisp's IF special form, you should
put your embedded language in its own package. Then you can do whatever
you want with FOOBAR:IF and not confuse anyone's compiler. That's one
of the applications we had in mind when designing the Common Lisp
package system, and I think that all the necessary features are there
for this kind of hackery.
-- Scott
∂01-Sep-84 2157 rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA "initial segments of the continued fraction lead to the best rational approximations"
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 1 Sep 84 21:56:44 PDT
Received: from SCRC-MISSISSIPPI by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83311; Sat 1-Sep-84 23:49:49-EDT
Date: Sat, 1 Sep 84 23:48 EDT
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-RIVERSIDE.ARPA>
Subject: "initial segments of the continued fraction lead to the best rational approximations"
To: rz@MIT-MC.ARPA
Cc: wholey@CMU-CS-C.ARPA, dlw%SPA-NIMBUS@SCRC-RIVERSIDE.ARPA,
common-lisp@SU-AI.ARPA
Yow, are you a lawyer yet? If "best rational approximations" are those which
are closer than any with smaller denominator, then your "leads to" is misleading,
since reducing the final term of a truncated cf by less than half its correct
value still gives a "best" approximation. Reducing by fully one half is
"best" in only about half of the (even) cases. The precise terms and conditions
are intelligible by anyone who has recently passed a Bar exam, and I will inflict
them only on the avowedly curious.
∂02-Sep-84 1404 KMP@MIT-MC documentation strings
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 14:04:16 PDT
Date: 2 September 1984 17:03-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: documentation strings
To: Moon @ SCRC-STONY-BROOK
cc: COMMON-LISP @ SU-AI
In-Reply-To:<840831164747.9.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri, 31 Aug 84 16:47 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Macros may expand into declarations. May macros expand into
documentation strings?
I remember discussing this. I don't remember if there was an outcome
and couldn't find it in Mary Poppins.
The problem is that declarations identify themselves by the car of the
form. Documentation strings don't. Hence,
(DEFMACRO FOO () "Foo")
(DEFUN BAR () (FOO) "Bar")
is clear enough, but:
(DEFMACRO DEFFROB (NAME &REST BODY)
`(DEFUN ,(SYMBOLCONC NAME '-FROB) () ,@BODY))
(DEFFROB FOO (FOO))
might be confusing in that a bogus documentation string might be
generated (assume the user doesn't know the implementation of either
FOO or DEFFROB). If you think it's unambiguous because (FOO) is in a
for-value situation, consider the conscientious macro-writer who knew
that the return value of frob functions were always ignored, so had
written instead:
(DEFMACRO DEFFROB (NAME &REST BODY)
`(DEFUN ,(SYMBOLCONC NAME '-FROB) () ,@BODY NIL))
to emphasize the fact. I find it distasteful to think that he'd have
to write
(DEFMACRO DEFFROB (NAME &REST BODY)
`(DEFUN ,(SYMBOLCONC NAME '-FROB) () NIL ,@BODY NIL))
to be safe. Unfortunately, this would mean (FOO) could not expand into
a declaration, which might have been desirable. His only alternative
is to write code to check the first n forms in BODY for
declarations/doc-strings, which is something of a pain to be doing
everywhere.
The only happy way around it is to require documentation strings to be
visually apparent. I would support a move to allow a new declaration type
called DOCUMENTATION such that a macro wanting to provide documentation
could expand to (DECLARE (DOCUMENTATION "...")), which would not be
ambiguous in the way that "..." at toplevel would be. A doc-string at
toplevel could be magic shorthand for this declaration.
-kmp
∂02-Sep-84 1845 GSB@MIT-MC (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 18:45:31 PDT
Date: 2 September 1984 21:46-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: (defmacro foo (&whole w) ...)
To: Common-Lisp @ SU-AI
The original intent of &whole when it was put into maclisp was for the
macro to have a handle on the form being macroexpanded; in that light
it is orthogonal to &rest or anything else, and even the case of
(defmacro foo (&whole w) ...) is not degenerate. Similarly, embedded
use of &whole gives one a pointer to a subform which is being further
destructured, and which you wouldn't otherwise be able to get a handle
on. If &whole inhibits too-many-arguments checking, then this
functionality becomes useless because you cannot use it and enforce
the structure at the same time.
∂02-Sep-84 2055 JonL.pa@Xerox.ARPA Re: (defmacro foo (&whole w) ...)
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 20:55:44 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 84 20:56:13 PDT
Date: 2 Sep 84 20:56 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: (defmacro foo (&whole w) ...)
In-reply-to: Glenn S. Burke <GSB@MIT-MC.ARPA>'s message of 2 Sep 84
21:46 EDT
To: GSB@MIT-MC.ARPA
cc: Common-Lisp@SU-AI.ARPA
You're right. &WHOLE, as originally conceived, was orthogonal to the
other keywords. I recommend that approach (you are also recommending
it, no?).
-- JonL --
∂02-Sep-84 2132 GSB@MIT-MC Re: (defmacro foo (&whole w) ...); macros ==> documentation strings
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 21:32:09 PDT
Date: 3 September 1984 00:31-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: Re: (defmacro foo (&whole w) ...); macros ==> documentation strings
To: Common-Lisp @ SU-AI
Yes, i am advocating &whole being orthogonal and not affecting the number-
of-argument checking.
As for macros expanding into documentation strings, i don't think that
this is a good idea, because while DECLARE is not permitted to appear
in arbitrary places, strings are. As a result, a misplaced macro
expanding into a DECLARE form is an error, whereas a misplaced macro
expanding into a documentation string is not, and might be interpreted
incorrectly even if it isn't misplaced. If this calls for a
DOCUMENTATION declaration, fine, add one.
∂02-Sep-84 2144 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 21:44:23 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 00:26:54-EDT
Date: Mon, 3 Sep 1984 00:26 EDT
Message-ID: <FAHLMAN.12044516802.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: JonL.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA, GSB@MIT-MC.ARPA
Subject: (defmacro foo (&whole w) ...)
In-reply-to: Msg of 2 Sep 1984 23:56-EDT from JonL.pa at XEROX.ARPA
If by "orthogonal" you mean that too-many-argument checking remains in
place, and that (defmacro foo (&whole x) ...) is required to have NO
subforms in argument position, then I'm against this interpretation.
Once you've given the user a handle on the whole argument form with
&whole, you shouldn't require him to add additional meaningless args
just to confuse Defmacro into allowing subforms without complaining.
That makes for confusing code. If the user actually wants to make use
of the additional args, that's different.
I'm not too concerned with what the original intent in Maclisp was.
Defmacro has evolved quite a bit since the first muddled attempts to do
something reasonable with macros. About the time I left MIT, there were
three or four defmacro-like packages in use by various people, all
different.
-- Scott
∂02-Sep-84 2217 FAHLMAN@CMU-CS-C.ARPA applyhook
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 22:17:32 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 00:59:39-EDT
Date: Mon, 3 Sep 1984 00:59 EDT
Message-ID: <FAHLMAN.12044522763.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: applyhook
In-reply-to: Msg of 31 Aug 1984 20:24-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
OK, I'll bite. Why do you think that applyhook doesn't need an
environment arg? Granted, the args have already been computed by the
time the applyhook gets called, but the environment still might be
needed while the function is running. Functions called by name in the
usual way carry their lexical environment around with them -- either the
null environment or a closure -- but the function being applied might be
an interpreted lambda containing code that refers to free variables,
lexicaly bound function names, and external GO and BLOCK tags. Such
things are looked up in the current lexical environment during the
application of the Lambda form to the args, right? Or am I confused
about this?
-- Scott
∂02-Sep-84 2245 ALAN@MIT-MC (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 2 Sep 84 22:45:35 PDT
Date: 3 September 1984 01:46-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: (defmacro foo (&whole w) ...)
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Mon 3 Sep 1984 00:26 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Mon, 3 Sep 1984 00:26 EDT
From: Scott E. Fahlman <Fahlman at CMU-CS-C>
Once you've given the user a handle on the whole argument form with
&whole, you shouldn't require him to add additional meaningless args
just to confuse Defmacro into allowing subforms without complaining.
That makes for confusing code. If the user actually wants to make use
of the additional args, that's different.
Huh? I don't understand what you are trying to say. Whats all this talk
about "confusing" defmacro? Glenn's agrument is very simple: Suppose the
user wants to get ahold of the original form, but also wants defmacro to
take it apart for him. Why should the fact that he wants to include the
whole form in an error message (for example) cause him to lose error
checking on the syntax of the macro call? If he wants to allow any length
form to be used, he can always add &REST IGNORE. I don't see anything
meaningless or confusing about that, it says what it means quite clearly.
BTW, Glenn also just convinced me that macros that expand into
documentation strings are potentially hazardous, I think the idea of an
explicit DOCUMENTATION declaration is clearly the right thing for macros
that want to supply documentation strings. The idea of using strings like
that was only a kludge to improve readability of the code anyway, macros
don't have to expand into readable code.
∂03-Sep-84 0657 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 06:57:28 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 09:40:05-EDT
Date: Mon, 3 Sep 1984 09:40 EDT
Message-ID: <FAHLMAN.12044617507.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: (defmacro foo (&whole w) ...)
In-reply-to: Msg of 3 Sep 1984 01:46-EDT from Alan Bawden <ALAN at MIT-MC>
Well, I guess what it boils down to for me is that in 95% of the cases
where there is an &WHOLE in a macro, that's all there is, and it's a
pain to have to write an explicit &REST argument when you could just
take the cdr of the &WHOLE arg. By the way, your "&REST IGNORE" must be
accompanied by (declare (ignore ignore)) in order to work in Common
Lisp. The special-case treatment of variables named IGNORE got flushed
in favor of the more uniform IGNORE declaration, I believe. The
question is whether it is more trouble and more confusing to have to add
that &REST arg and the IGNORE declaration in a lot of places, or to put
in an explicit length check on the &WHOLE are in the rare case that you
want the arglist to have some maximum length.
Actually, I have seen &WHOLE used in only two ways: first, when you're
in a macro with some sort of complex syntax and don't want the usual
argument destructuring (in which case, it is best to disable the
too-many-args check); second, in cases where you do want normal
destructuring, but need to get at the CAR of the calling form. I'd like
to see an additional form for that specialized purpose: something like
&first (though I'd like to find a better name for it). That would
clarify the programmer's intention and would not disable arg-count
checking.
Of course, if I am wrong about this and people are writing lots of code
that mixes &whole (for some use other than getting at the car of the form)
and hairy arglist destructuring, then &whole should be orthogonal after
all. We may have a cultural difference here.
-- Scott
∂03-Sep-84 0737 RAM@CMU-CS-C.ARPA applyhook
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 07:36:57 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Mon 3 Sep 84 10:19:00-EDT
Date: Mon, 3 Sep 1984 10:18 EDT
Message-ID: <RAM.12044624579.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA, "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: applyhook
In-reply-to: Msg of 3 Sep 1984 00:59-EDT from Scott E. Fahlman <Fahlman>
It's not clear that:
(let ((a 'foo))
(apply '(lambda () a) ()))
has to work in Common Lisp. The lambda should be #'ed, in which case
it will be closed over. It is not totally clear in the CLM what the
effect of using a quoted lambda is, but it would seem to dubious since
it cannot be compiled properly and the compiler is required to
implement the same semantics as the interpreter.
Rob
∂03-Sep-84 0850 FAHLMAN@CMU-CS-C.ARPA applyhook
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 08:50:08 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 11:32:48-EDT
Date: Mon, 3 Sep 1984 11:32 EDT
Message-ID: <FAHLMAN.12044638023.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: applyhook
In-reply-to: Msg of 3 Sep 1984 10:18-EDT from Rob MacLachlan <RAM>
Rob,
I don't think the example you give has anything to do with *APPLYHOOK*.
*APPLYHOOK* is supposed to intercept the implicit calls to apply that
occur within EVAL. It is not supposed to handle explicit calls done by
APPLY, FUNCALL, MAP, etc. See page 322. The name "applyhook" is a bit
confusing because of this, but I can't think of any better name.
I believe that the final decision on forms like
(apply '(lambda (x) ... code ...) ...)
was that they were allowed, but that the lambda was executed in the NULL
lexical environment. As you say, if it has to use the current lexical
environment there's no way to compile it in the general case where the
lambda-form may be generated at runtime. However, I can't find any
discussion of this in the manual and may be misremembering the decision.
I do remember that discussions of this dragged on for quite awhile.
-- Scott
∂03-Sep-84 1550 ALAN@MIT-MC (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 15:50:36 PDT
Date: 3 September 1984 18:51-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: (defmacro foo (&whole w) ...)
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Mon 3 Sep 1984 09:40 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Mon, 3 Sep 1984 09:40 EDT
From: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Well, I guess what it boils down to for me is that in 95% of the cases
where there is an &WHOLE in a macro, that's all there is, and it's a
pain to have to write an explicit &REST argument when you could just
take the cdr of the &WHOLE arg....
I don't buy any argument that says we have to make certain things
impossible for users to do just because you find it a pain to have to write
"&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year.
Excuse me for forgetting the "(DECLARE (IGNORE IGNORE))" before. If I had
been able to have my way on that issue, you wouldn't ever have to write
that.
I don't go for this &FIRST idea either. I don't like introducing yet more
silly &keywords when we could render &FIRST next to useless by simply
defining &WHOLE not to gratuitously disable an error check.
∂03-Sep-84 1646 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 16:46:11 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 19:46:24-EDT
Date: Mon, 3 Sep 1984 19:46 EDT
Message-ID: <FAHLMAN.12044727886.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: (defmacro foo (&whole w) ...)
In-reply-to: Msg of 3 Sep 1984 18:51-EDT from Alan Bawden <ALAN at MIT-MC>
I don't buy any argument that says we have to make certain things
impossible for users to do just because you find it a pain to have to write
"&REST IGNORE) (DECLARE (IGNORE IGNORE))" twice a year.
What, exactly, would become impossible if we turned off too-many-argument
checking when an &whole is encountered? Looks to me like Common Lisp
would still be more or less Turing equivalent. To me, the question is
whether it is more of a pain for me to write "&REST IGNORE) (DECLARE
(IGNORE IGNORE))" twice a year or for you to write
(WHEN (> (LENGTH WHOLE-ARG) 7)
(ERROR "Too many args to FOO."))
twice a century. As I said, if I'm off base on the relative frequencies
of these things in other parts of the user community, then the
orthogonal approach might be preferable. But I don't see any
impossibility in either approach that would force us to choose the less
convenient of the two.
-- Scott
∂03-Sep-84 1722 ALAN@MIT-MC (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 17:22:24 PDT
Date: 3 September 1984 20:23-EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject: (defmacro foo (&whole w) ...)
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Mon 3 Sep 1984 19:46 EDT from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Date: Mon, 3 Sep 1984 19:46 EDT
From: Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
What, exactly, would become impossible if we turned off too-many-argument
checking when an &whole is encountered? Looks to me like Common Lisp
would still be more or less Turing equivalent. To me, the question is
whether it is more of a pain for me to write "&REST IGNORE) (DECLARE
(IGNORE IGNORE))" twice a year or for you to write
(WHEN (> (LENGTH WHOLE-ARG) 7)
(ERROR "Too many args to FOO."))
This is not an acceptable substitute for having defmacro perform the error
checking automatically. It requires the user to count the number of
arguments by hand; if he inserts a new argument, he has to remember to go
and increment a number imbedded in his code. More importantly it assumes
that the user can duplicate the way defmacro signals the error, which in
general he cannot.
∂03-Sep-84 1802 FAHLMAN@CMU-CS-C.ARPA (defmacro foo (&whole w) ...)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 18:02:35 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 3 Sep 84 21:02:51-EDT
Date: Mon, 3 Sep 1984 21:02 EDT
Message-ID: <FAHLMAN.12044741799.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Alan Bawden <ALAN@MIT-MC.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: (defmacro foo (&whole w) ...)
In-reply-to: Msg of 3 Sep 1984 20:23-EDT from Alan Bawden <ALAN at MIT-MC>
Well, OK. I don't think it is very important to mix &whole with other
things, and if we do I don't think it's very important to catch
too-many-args errors, let alone to signal them in the canonical way
rather than in some other way. But I've got to admit that your way is
cleaner. You win, as far as I'm concerned.
Now, what about arglists with ONLY an &whole argument? Should we adopt
Moon's suggestion that these, as a special case, can accept any number
of subforms, or should we require the explicit &rest arg here as well?
This special case would eliminate most of the inconvenience I was
objecting to before, and this use seems clear and intuitive to me, but
it IS a special case. How muich does that bother people? Does anyone
really want an automatically generated check to ensure that there are NO
subforms?
-- Scott
∂03-Sep-84 1824 GSB@MIT-MC (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 18:24:06 PDT
Date: 3 September 1984 21:24-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: (defmacro foo (&whole w) ...)
To: Fahlman @ CMU-CS-C
cc: Common-Lisp @ SU-AI
Date: Mon, 3 Sep 1984 21:02 EDT
Sender: FAHLMAN@CMU-CS-C.ARPA
Now, what about arglists with ONLY an &whole argument? Should we adopt
Moon's suggestion that these, as a special case, can accept any number
of subforms, or should we require the explicit &rest arg here as well?
This special case would eliminate most of the inconvenience I was
objecting to before, and this use seems clear and intuitive to me, but
it IS a special case. How muich does that bother people? Does anyone
really want an automatically generated check to ensure that there are NO
subforms?
It should be entirely self-consistent: (&whole w) should bind w to
the macro form, and REQUIRE no arguments. If what you want is to hack
with arbitrary arguments, just use (&rest args), and i bet you don't want
the car of the form most the time then anyway.
∂03-Sep-84 2257 GS70@CMU-CS-A.ARPA '(lambda () a)
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 22:56:54 PDT
Date: 4 Sep 84 0156 EDT (Tuesday)
From: Guy.Steele@CMU-CS-A.ARPA
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Subject: '(lambda () a)
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <RAM.12044624579.BABYL@CMU-CS-C.ARPA>
It is true that
(let ((a 'foo))
(apply '(lambda () a) ()))
need not yield the value foo when executed in Common LISP.
However, it does have a valid interpretation. Sections 2.13 and 5.2
refer to the fact that a "raw lambda expression" may be used as
a function; see also the description of the function APPLY.
I remember that we decided that a raw lambda expression, when applied,
is supposed to be implicitly closed in the null (that is, global)
environment, but I cannot quickly find a place in the manual that
actually says that. Gulp.
--Guy
∂03-Sep-84 2343 masinter.pa@Xerox.ARPA &whole
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Sep 84 23:42:53 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 03 SEP 84 23:43:21 PDT
From: masinter.pa@XEROX.ARPA
Date: 3 Sep 84 23:42:50 PDT
Subject: &whole
To: Common-Lisp@SU-AI.ARPA
I usually try to stay out of these but...
it seems that &whole is pretty much of a hack, but if you are gonna
leave it in, there is no point in hacking it up further.
&whole should be treated like &rest: does it make sense to say
(lambda (a b &rest c d e) --)
where c is bound to the tail and d and e are respectively the car and
cadr of c with arg count checking turned on?
one way around the dilemma of argument checking is to include a
macro/special form:
(destructure-args form (arg1 arg2 arg3) ...)
which 'destructured' form, performed the same arg checking that macro
expansion did, and then executed ....
Where you would have the user write
(defmacro foo (&whole whoarg a b ) ---)
which is pretty confusing, he would write
(defmacro foo (&whole whoarg)
(destructure-arg whoarg (a b) --))
makes a little more sense, and doesn't rely on obscure rules about
arglists etc.
Sorry for intruding...
Larry
∂04-Sep-84 1552 JonL.pa@Xerox.ARPA Re: (defmacro foo (&whole w) ...)
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Sep 84 15:51:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 84 15:51:06 PDT
Date: 4 Sep 84 15:51 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: (defmacro foo (&whole w) ...)
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
Mon, 3 Sep 84 09:40 EDT
To: Fahlman@CMU-CS-C.ARPA
cc: ALAN@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA
I may have been the first (long ago at MIT) to make extensive use of
&whole. But that aside, none of my usages fit in the the two molds you
suggest: [1] don't like default destructuring, or [2] want to know the
code name that invoked the macro (your &first).
It was primarily for the more proseaic reason that GSB (or ALAN?)
suggested -- simply to give a direct handel on the offending form to the
error handler. This is especially relevant when one takes to using
precisely one expander function as the "macro" for, say, three different
symbols (but &first could serve the functional part here ok).
Mail subsequent to this note of yours seems to suggest to me that the
"orthogonality" issue hasn't been fully understood. One should just
pretend that DEFMACRO works exactly like it does before any
consideration of &whole, but the macro body can fortuitously access the
invoking form via some variable. This latter part is the one piece of
functionality that DEFMACRO lacks when compared to MACRO; and I tend to
agree with you that 95% (yea, 99%) of all correct macro usages can
generally be expressed in the DEFMACRO format.
-- JonL --
∂04-Sep-84 2336 DLW@SCRC-STONY-BROOK.ARPA (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Sep 84 23:36:28 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 83908; Tue 4-Sep-84 16:17:50-EDT
Date: Tue, 4 Sep 84 16:16 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: (defmacro foo (&whole w) ...)
To: GSB@MIT-MC.ARPA, Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Sep 84 21:24-EDT from Glenn S. Burke <GSB at MIT-MC>
Message-ID: <840904161614.2.DLW@CHICOPEE.SCRC.Symbolics>
Date: 3 September 1984 21:24-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
It should be entirely self-consistent: (&whole w) should bind w to
the macro form, and REQUIRE no arguments. If what you want is to hack
with arbitrary arguments, just use (&rest args), and i bet you don't want
the car of the form most the time then anyway.
I agree. Common Lisp needs as much consistency and simplicity as it can
get, at this point.
∂05-Sep-84 0119 Moon@SCRC-QUABBIN.ARPA applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 01:18:13 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78090; Tue 4-Sep-84 16:13:15-EDT
Date: Tue, 4 Sep 84 16:19 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: applyhook
To: Common-Lisp@SU-AI.ARPA
References: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>,
<FAHLMAN.12044522763.BABYL@CMU-CS-C.ARPA>,
<RAM.12044624579.BABYL@CMU-CS-C.ARPA>,
<RAM.12044624579.BABYL@CMU-CS-C.ARPA>,
<FAHLMAN.12044638023.BABYL@CMU-CS-C.ARPA>,
The message of 4 Sep 84 01:56-EDT from Guy.Steele at CMU-CS-A,
<840904152033.7.MOON@EUPHRATES.SCRC.Symbolics>
Message-ID: <840904161914.8.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri, 31 Aug 84 20:24 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
APPLYHOOK should not take an &OPTIONAL ENV argument.
Similarly *APPLYHOOK* should receive two arguments, not three arguments.
An environment is not meaningful for the APPLY operation, only for the EVAL operation.
Does anyone disagree?
The only RELEVANT remark among the mail I've received on the subject so far was
from Glenn Burke, who suggested that this ENV argument to APPLYHOOK may be
for the case of evaluating
((lambda ...) ...)
which of course is supposed to be trapped by APPLYHOOK. My feeling is that the
hook should see a lexical closure of the lambda, rather than getting the raw lambda
and the environment as separate arguments. My system actually doesn't work that
way, for stupid reasons; I am about to change it to work that way.
Any opinions?
∂05-Sep-84 0119 Moon@SCRC-QUABBIN.ARPA &whole
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 01:16:27 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78088; Tue 4-Sep-84 16:06:42-EDT
Date: Tue, 4 Sep 84 16:12 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: &whole
To: masinter.pa@XEROX.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 4 Sep 84 02:42-EDT from masinter.pa at XEROX
Message-ID: <840904161240.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: 3 Sep 84 23:42:50 PDT
From: masinter.pa@XEROX.ARPA
one way around the dilemma of argument checking is to include a
macro/special form:
(destructure-args form (arg1 arg2 arg3) ...)
which 'destructured' form, performed the same arg checking that macro
expansion did, and then executed ....
This is called destructuring-bind, but it's not in Common Lisp. Suggestions
for better names are welcome. I think the lousy name is the reason why I
didn't push for including it in Common Lisp.
∂05-Sep-84 0706 FAHLMAN@CMU-CS-C.ARPA &whole
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 07:06:11 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Sep 84 10:05:48-EDT
Date: Wed, 5 Sep 1984 10:05 EDT
Message-ID: <FAHLMAN.12045146464.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA
Subject: &whole
In-reply-to: Msg of 4 Sep 1984 16:12-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I'm ready to give up and go with total orthogonality for &whole. So
(defmacro foo (&whole x) ...) would complain if there are any
"arguments", and you have to put in an &rest if you want that complaint
to go away.
I think destructuring bind would be a good thing to have in the language
in any event. Maybe DBIND would be an adequate name? To avoid
confusion, the arglist syntax would have to be exactly as in defmacro.
Earlier proposals for DLET and DSETQ were tabled because there was
substantial disagreement on the syntax for these, but a form that
parallels arglist parsing in a defmacro would be conceptually clear and
trivial to implement (given existing code for defmacro).
-- Scott
∂05-Sep-84 0724 FAHLMAN@CMU-CS-C.ARPA applyhook
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 07:24:31 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Sep 84 10:24:10-EDT
Date: Wed, 5 Sep 1984 10:24 EDT
Message-ID: <FAHLMAN.12045149818.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: applyhook
In-reply-to: Msg of 4 Sep 1984 16:19-EDT from David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
I'm not sure why GSB's mail about ((lambda ...) ...) being the reason
for the env argument to applyhook is relevant and my note pointing out
the same problem is not. I hope the various mailers are not losing
things again. But anyway...
If this is the only problem that people have found, and as far as I know
it is, then Moon's suggestion of passing the lambda form in to the
applyhook as an instant closure would work OK, and would not hurt
performance in the normal case, since if there's a non-null applyhook a
different calling sequence must be used in any event. (The args must go
into a list rather than onto the stack.)
My only remaining question is whether it is worth the hassle to
eliminate the env argument just because it is possible to do so. This
seems to be a gratuitous change (not a clarification) from the published
specification for no particularly compelling reason. It will cause
confusion among implementors (and perhaps a few users) who are not on
this mailing list and who do not hear about this change. Until some
sort of formal means of announcing changes to the spec is set up, we
should probably avoid incompatible changes unless the reason for making
the change is really compelling.
-- Scott
∂05-Sep-84 0801 Moon@SCRC-QUABBIN.ARPA documentation strings
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 08:00:31 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78116; Tue 4-Sep-84 16:53:26-EDT
Date: Tue, 4 Sep 84 16:59 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: documentation strings
To: Kent M Pitman <KMP@MIT-MC.ARPA>, COMMON-LISP@SU-AI.ARPA
In-Reply-To: The message of 2 Sep 84 17:03-EDT from Kent M Pitman <KMP at MIT-MC>
Message-ID: <840904165927.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: 2 September 1984 17:03-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Date: Fri, 31 Aug 84 16:47 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Macros may expand into declarations. May macros expand into
documentation strings?
.... The only happy way around it is to require documentation strings to be
visually apparent. I would support a move to allow a new declaration type
called DOCUMENTATION such that a macro wanting to provide documentation
could expand to (DECLARE (DOCUMENTATION "...")), which would not be
ambiguous in the way that "..." at toplevel would be. A doc-string at
toplevel could be magic shorthand for this declaration.
This is more or less how we implement it anyway, so I'd support this too.
Currently in my implementation macros may expand into documentation
strings, just because that's the way the code happened to work out, but
I think that this is a misfeature and will probably make the code more
complex so that it will cease to recognize strings resulting from
macroexpansion as documentation.
∂05-Sep-84 0809 Moon@SCRC-QUABBIN.ARPA (defmacro foo (&whole w) ...)
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 08:09:12 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78183; Tue 4-Sep-84 21:27:16-EDT
Date: Tue, 4 Sep 84 21:33 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: (defmacro foo (&whole w) ...)
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <840829225336.4.MOON@EUPHRATES.SCRC.Symbolics>,
<840830164339.6.MOON@EUPHRATES.SCRC.Symbolics>,
The message of 2 Sep 84 21:46-EDT from Glenn S. Burke <GSB at MIT-MC>,
The message of 2 Sep 84 23:56-EDT from JonL.pa at XEROX,
<FAHLMAN.12044516802.BABYL@CMU-CS-C.ARPA>,
The message of 3 Sep 84 00:31-EDT from Glenn S. Burke <GSB at MIT-MC>,
The message of 3 Sep 84 01:46-EDT from Alan Bawden <ALAN at MIT-MC>,
<FAHLMAN.12044617507.BABYL@CMU-CS-C.ARPA>,
The message of 3 Sep 84 18:51-EDT from Alan Bawden <ALAN at MIT-MC>,
<FAHLMAN.12044727886.BABYL@CMU-CS-C.ARPA>,
The message of 3 Sep 84 20:23-EDT from Alan Bawden <ALAN at MIT-MC>,
<FAHLMAN.12044741799.BABYL@CMU-CS-C.ARPA>,
The message of 3 Sep 84 21:24-EDT from Glenn S. Burke <GSB at MIT-MC>,
The message of 4 Sep 84 02:42-EDT from masinter.pa at XEROX
Message-ID: <840904213316.4.MOON@EUPHRATES.SCRC.Symbolics>
Y'all convinced me that the presence of &WHOLE should have no effect on the
number-of-subforms checking. Having to put in &REST IGNORE in six places in
a large program is better than having an inconsistency in the language.
This is consistent with the manual, which says nothing about number-of-subforms
checking in defmacro, except at the bottom of p.147 where it says that an
implementation "may" do it.
∂05-Sep-84 1145 goldman@ISI-VAXA please add me to the mailing list
Received: from ISI-VAXA.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 11:44:53 PDT
Date: Wednesday, 5 Sep 1984 11:40-PDT
TO: COMMON-LISP at SU-AI
FROM: Goldman at ISI-VAXA
SUBJECT: please add me to the mailing list
∂05-Sep-84 1249 Moon@SCRC-STONY-BROOK.ARPA applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 12:48:48 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 84522; Wed 5-Sep-84 15:51:21-EDT
Date: Wed, 5 Sep 84 15:49 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: applyhook
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12045149818.BABYL@CMU-CS-C.ARPA>
Message-ID: <840905154916.0.MOON@EUPHRATES.SCRC.Symbolics>
Date: Wed, 5 Sep 1984 10:24 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
My only remaining question is whether it is worth the hassle to
eliminate the env argument just because it is possible to do so. This
seems to be a gratuitous change (not a clarification) from the published
specification for no particularly compelling reason. It will cause
confusion among implementors (and perhaps a few users) who are not on
this mailing list and who do not hear about this change. Until some
sort of formal means of announcing changes to the spec is set up, we
should probably avoid incompatible changes unless the reason for making
the change is really compelling.
My point of view is that this is a correction of two typographical errors
in the manual, rather than an incompatible change to the language; one place
on page 322 implies that the function that is the value of *applyhook*
receives only two arguments. I could well be wrong.
Regardless of this particular issue, we do need to set up a mechanism for
distribution of corrections to the manual (as opposed to changes to the
language). This topic is missing from the agenda for the Monterey meeting,
but it's certainly more important than some of the other things on that
agenda (perhaps it is subsumed under "procedures for maintaining the CL
standard") and we should talk about it anyway. See you there.
∂05-Sep-84 1345 Moon@SCRC-STONY-BROOK.ARPA &whole
Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 5 Sep 84 13:45:26 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 84563; Wed 5-Sep-84 16:47:24-EDT
Date: Wed, 5 Sep 84 16:45 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: &whole
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
cc: Common-Lisp@SU-AI.ARPA, masinter.pa@XEROX.ARPA
In-Reply-To: <FAHLMAN.12045146464.BABYL@CMU-CS-C.ARPA>
File-References: MC: MOON; CL DSTRUC
Message-ID: <840905164518.2.MOON@EUPHRATES.SCRC.Symbolics>
Date: Wed, 5 Sep 1984 10:05 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
I think destructuring bind would be a good thing to have in the language
in any event. Maybe DBIND would be an adequate name?
The part of the name I object to is the word "bind", not the word "destructuring"!
To keep my criticism constructive, I'll propose DESTRUCTURE as a name.
On the other hand, Common Lisp did not change the name of MULTIPLE-VALUE-BIND,
which is an extremely analogous form that simply does a different kind of
destructuring, so maybe DESTRUCTURING-BIND is not such a bad name.
To avoid
confusion, the arglist syntax would have to be exactly as in defmacro.
Of course, you have to specify an object to be destructured, you cannot
use &ENVIRONMENT, and DEFMACRO's magic cdr-ization of &WHOLE when seen at
the top level is not performed. Otherwise it's the same as DEFMACRO.
Incidentally, we put the argument pattern -before- the object to be
destructured, rather than -after- (as in Masinter's recent message).
This is based on the philosophy that special forms that bind variables
should always have the variables at the front of the form.
It might be desirable to have two forms, with and without error checking
that the pattern matches the object in shape and length. Currently we
have only the without-error-checking form, but the with-error-checking
form would be more consistent with DEFMACRO. The two forms could either
have two names (a la CASE, ECASE, CCASE) or could be distinguished by
an & keyword (a la &optional and &allow-other-keys).
Earlier proposals for DLET and DSETQ were tabled because there was
substantial disagreement on the syntax for these, but a form that
parallels arglist parsing in a defmacro would be conceptually clear and
trivial to implement (given existing code for defmacro).
Agreed. I can write a formal proposal after the Monterey meeting if there
is interest.
There are other possible kinds of destructuring besides this one, which should
not affect adoption of this one, but may be of interest. The file referenced
in the header of this message, which can be retrieved from MIT-MC with anonymous
FTP, contains a discussion I wrote last year of some of the issues. It does not
make any proposals, it only discusses.
Those poor wretches who are stuck with a user FTP program that refuses to allow
spaces in file names on the foreign host may send me mail and I will mail them a
copy of the file.
∂05-Sep-84 1421 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 14:21:20 PDT
Date: Wed 5 Sep 84 17:23:17-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: applyhook
To: common-lisp@SU-AI.ARPA
Seems to me you want to keep the environment argument with applyhook
for the same reason it's there with evalhook: because you want an
explicit handle on the environment so you can implement things like
the stepper and the debugger.
---Walter
-------
∂05-Sep-84 1542 JonL.pa@Xerox.ARPA Re: &whole
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 15:42:31 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 05 SEP 84 15:42:31 PDT
Date: 5 Sep 84 15:29 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: &whole
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
Wed, 5 Sep 84 10:05 EDT
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
You may remember that since 1979, MacLisp (and NIL too, I believe) have
had DESETQ for a "destructuring" version of SETQ, and have extended
DEFUN and LET to do full destructuring on their "lambda" lists. (ALAN
may also have produced a version of these things for the Lisp Machine).
There was a small amount of discussion on this point, oh maybe two years
ago, in the Common Lisp mails, with one suggestion being to extend the
notion of destructuring/lambda-binding to every position that is
"analogous" -- this would mean in the lambda-list of DEFUN, in lambda
applications like
((LAMBDA (...) ...) ...)
as well as in LET.
The idea died back then because enough people didn't see a compelling
similarity between the argument "spreading" (Interlisp word!) in
DEFMACRO and that in the other places like DEFUN.
-- JonL --
∂05-Sep-84 1837 FAHLMAN@CMU-CS-C.ARPA &whole
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 18:35:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 5 Sep 84 21:35:11-EDT
Date: Wed, 5 Sep 1984 21:35 EDT
Message-ID: <FAHLMAN.12045271974.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: JonL.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: &whole
In-reply-to: Msg of 5 Sep 1984 18:29-EDT from JonL.pa at XEROX.ARPA
Yeah, I remember most of that discussion. My position was (and still
is) that specific destructuring forms like DELET and DESETQ would be
fine, if we could agree on the syntax and come up with better names than
those, but that I was (and still am) adamantly opposed to any attempt to
incorporate destructuring into existing forms like DEFUN, LET, and SETQ.
One reason why we never made any progress on defining a set of standard
destructuring operations is that every time the subject came up, it
turned into an argument about whether to mess with Defun and all the
other existing forms that might also be destructured.
My vote would be to consider the proposed Destructuring-Bind by itself,
without getting into those related issues yet again.
I guess I don't see any need for a non-error checking version of this.
Can anyone suggest a situation in which such a thing would be useful?
-- Scott
∂05-Sep-84 2213 Moon@SCRC-QUABBIN.ARPA Re: applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Sep 84 22:12:51 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 78852; Thu 6-Sep-84 01:06:21-EDT
Date: Thu, 6 Sep 84 01:12 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: applyhook
To: Walter van Roggen <WVANROGGEN@DEC-MARLBORO.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 5 Sep 84 17:23-EDT from Walter van Roggen <WVANROGGEN at DEC-MARLBORO>
Message-ID: <840906011237.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: Wed 5 Sep 84 17:23:17-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Seems to me you want to keep the environment argument with applyhook
for the same reason it's there with evalhook: because you want an
explicit handle on the environment so you can implement things like
the stepper and the debugger.
But my point is that there is no environment associated with the operation
of applying a function to arguments.
∂06-Sep-84 0614 DLW@SCRC-STONY-BROOK.ARPA &whole
Received: from [128.31.41.144] by SU-AI.ARPA with TCP; 6 Sep 84 06:13:52 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 85110; Thu 6-Sep-84 08:52:18-EDT
Date: Thu, 6 Sep 84 08:52 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: &whole
To: Fahlman@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12045271974.BABYL@CMU-CS-C.ARPA>
Message-ID: <840906085209.9.DLW@CHICOPEE.SCRC.Symbolics>
I agree with you completely.
We should be careful to define the error-checking behavior that this
function must meet. The one presently installed on the Lisp Machine
doesn't check if a list is too long NOR if a list is too short -- in the
latter case the variable is bound to NIL. However, it does signal an
error if it tries to CAR into an atom. I don't know whether this
behavior is intentional or a bug.
∂06-Sep-84 0827 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 08:27:14 PDT
Date: Thu 6 Sep 84 11:28:26-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: applyhook
To: Moon@SCRC-STONY-BROOK.ARPA
cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from ""David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>" of Thu 6 Sep 84 01:20:28-EDT
And my point was there's no way to get the "environment" part of a
closure explicitly. Sure, implementors don't have to use it because
they have access to the internals; but CL users won'be able to
evaluate forms in the environment current at the application otherwise.
Unless there's some contorted hack you can pull using EVALHOOK.
---Walter
-------
∂06-Sep-84 1512 KMP@MIT-MC applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 15:11:57 PDT
Date: 6 September 1984 18:10-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: applyhook
To: WVANROGGEN @ DEC-MARLBORO
cc: common-lisp @ SU-AI, Moon @ SCRC-STONY-BROOK
In-reply-to: Msg of Thu 6 Sep 84 11:28:26-EDT from Walter van Roggen <WVANROGGEN at DEC-MARLBORO.ARPA>
Date: Thu 6 Sep 84 11:28:26-EDT
From: Walter van Roggen <WVANROGGEN at DEC-MARLBORO.ARPA>
And my point was there's no way to get the "environment" part of a
closure explicitly. Sure, implementors don't have to use it because
they have access to the internals; but CL users won'be able to
evaluate forms in the environment current at the application otherwise.
Unless there's some contorted hack you can pull using EVALHOOK....
Given:
((LAMBDA (Y) ((LAMBDA (X) (+ X Y)) 4)) 3)
You can get traps at:
Data Env Hook
1 ((LAMBDA (Y) ...) 4) () EVALHOOK
2 (LAMBDA (Y) ...), (4) none APPLYHOOK
3 ((LAMBDA (X) ...) 3) ((Y 4)) EVALHOOK
4 (LAMBDA (X) ...), (3) none APPLYHOOK
5 (+ X Y) ((X 3) (Y 4)) EVALHOOK
The situation you're worried about is not having the environment at point
2 and 4. But since no destructive computation ever happens between situations
like 2 and 3 or 4 and 5, it doesn't matter. Whatever code you intended to
run at 2 and 4 can just as well run at 3 and 5 where the info is available.
Really, though, APPLYHOOK and EVALHOOK are not as closely related as
you are trying to make them seen. They're both useful in debugging, but
for much different things.
EVALHOOK is generally used to monitor the local state within a lexical
contour, making sure that evaluation is proceeding correctly in that
context.
APPLYHOOK is used to monitor transitions between one lexical contour
and another. When travelling through that path, the only information
you carry with you is the parameters you pass (and special variables,
which are available at all times anyway). It would be inappropriate for
APPLYHOOK to get an ENV arg because it's between two contours; I am not
even clear on whether you are asking for it to receive the contour
of the state you're coming from or that of the state you're going to.
In any case, I think it simply shouldn't get any at all.
Do you agree with this? Can you suggest a non-contrived application
which contradicts this line of reasoning?
-kmp
∂06-Sep-84 1516 KMP@MIT-MC More (unrelated) EVALHOOK issues
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 15:16:23 PDT
Date: 6 September 1984 18:16-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: More (unrelated) EVALHOOK issues
To: Common-Lisp @ SU-AI
While I'm thinking about it (something I should have brought up ages ago,
but it might as well at least be on the books)...
There's a problem with EVALHOOK in that it really wants to pass a locative
to the piece of code that's being EVAL'd. Consider the problem of a
display-oriented stepper, trying to evaluate:
(LAMBDA (X) (+ X X))
when EVALHOOK traps on evaluating X, how can you know which X you are
evaluating so as to highlight it. If you think it's fair to assume that
the lexically first X is the one that leads you there, consider:
(LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y))))
It would have been nice if we had made it so the form passed in was a
list whose CAR was the form to be evaluated rather than the form itself.
That way, in the first example above, EVALHOOK could see
(X X)
and in the second, (X). Or perhaps that could be passed in as an extra
arg, being NIL when there was no locative available.
This shortcoming in the info provided by EVALHOOK has come up in
several stepper projects at MIT, and I should have mentioned it before,
but it should be thought about when time for revisions comes along.
-kmp
∂06-Sep-84 2258 DDYER@USC-ISIB.ARPA Re: More (unrelated) EVALHOOK issues
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 6 Sep 84 22:58:18 PDT
Date: 6 Sep 1984 22:56:05 PDT
Subject: Re: More (unrelated) EVALHOOK issues
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: Kent M Pitman <KMP@MIT-MC.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: (Message from "Kent M Pitman <KMP@MIT-MC.ARPA>" of 6 September 1984 18:16-EDT)
I agree that this is a lack in EVALHOOK, but the same also occurs
in debugging generally. The problem is that not enough state of
the interpreter is available to analysis/error handling tools, of
which an EVALHOOK routine is a good example.
In Interlisp, this isn't a problem because the temporaries of the
interpreter are explicitly available.
-------
∂07-Sep-84 1104 FAHLMAN@CMU-CS-C.ARPA &whole
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 11:04:48 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 7 Sep 84 14:03:51-EDT
Date: Fri, 7 Sep 1984 14:03 EDT
Message-ID: <FAHLMAN.12045714092.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Carl Hoffman <CWH@SCRC-QUABBIN.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: &whole
In-reply-to: Msg of 6 Sep 1984 22:23-EDT from Carl Hoffman <CWH at SCRC-QUABBIN.ARPA>
I'm sure I've found times when not having the error-checking has been useful.
For instance, suppose I have a long (or circular) list of triples.
I might want to destructure the first two entries of that list like so.
(DO () (NIL)
(DESTRUCTURING-BIND ((A1 B1 C1) (A2 B2 C2)) LIST ...)
(SETQ LIST (CDDR LIST)))
But you can inhibit the error checking by putting an "&rest ignore" in
there, and then you don't have to make a special non-error checking
version. Isn't this exactly analogous to the discussion we just had
about &whole ?
-- Scott
∂07-Sep-84 1340 KMP@MIT-MC EVALHOOK maintaining independent evaluation stacks
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 13:38:50 PDT
Date: 7 September 1984 16:35-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: EVALHOOK maintaining independent evaluation stacks
To: Moon @ SCRC-STONY-BROOK
cc: Common-Lisp @ SU-AI
References: Msg of of 6 Sep 84 18:16-EDT from Kent M Pitman <KMP @ MIT-MC>
In-Reply-To: <840906223648.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: Thu, 6 Sep 84 22:36 EDT
From: David A. Moon <Moon at SCRC-STONY-BROOK.ARPA>
Date: 6 September 1984 18:16-EDT
From: Kent M Pitman <KMP @ MIT-MC>
While I'm thinking about it ... There's a problem with EVALHOOK
in that it really wants to pass a locative to the piece of code
that's being EVAL'd. Consider the problem of a display-oriented
stepper, trying to evaluate:
(LAMBDA (X) (+ X X))
... If you think it's fair to assume that the lexically first X
is the one that leads you there, consider:
(LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y))))
I don't see why the user hook function can't maintain its own evaluation
stack, back which it can look. In general, of course, this requires it
to understand special forms. Your scheme, on the other hand, would require
EVAL to be completely remodularized, since it does not currently receive
the arguments it would need to compute the information you want in any
system I know of.
In order to do this correctly, you must presuppose the complete semantics
of the interpreter. You might as well write your own DEBUG-EVAL which
doesn't use EVAL at all. Part of the idea of EVALHOOK is to let EVAL do
what it wants (handling hard cases, etc) and leave the relevant (and
incidentally much easier) stuff to the hook.
Without understanding making all these assumptions, an evaluation history
isn't going to tell you what X is being evaluated after the throw in:
(BAR (*CATCH 'FOO (FOO (*THROW 'FOO NIL) X (FROB X))) X)
In order to know that, you'd have to know about the semantics of
catch/throw in a relatively intimate way.
Similarly, you might get faked out by which X was being evaluated after
the call to EVAL in
(PROGN (EVAL '(+ X 3)) X)
though APPLYHOOK might give you enough of a handle to get around this one.
I'm not sure. Page 322 of the CL manual suggests that APPLYHOOK wouldn't
help in the case of:
(PROGN (MAPCAR #'EVAL '((+ X 3))) X)
By the way, it does not affect my argument that the two X's in question are
not in the same lexical contour. If anything, it strengthens the importance
of the argument.
Even in this example (from my last message), where we've just EVAL'd (FOO):
(COND ((FOO) X Y)
(T X)),
you cannot which X is going to be evaluated without building into your
EVALHOOK an assumption about what COND does.
Does this help? I really believe that an explicit stack maintained by
EVALHOOK doesn't work, or that the work involved in coercing it work is at
least as great and probably more dangerous (in terms of being potentially
wrong) than that of just writing another evaluator. We tried that and it
fails in tricky code. Tricky code, by the way, is the sort of thing you
most need steppers to work on, I might add. In heavily macrofied code, you
can really get cases of throws out of arg positions, etc. that are
completely meaningful and I think not unreasonable to want to support.
-kmp
∂07-Sep-84 1558 WVANROGGEN@DEC-MARLBORO.ARPA Re: applyhook
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 7 Sep 84 15:58:18 PDT
Date: Fri 7 Sep 84 19:00:15-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Subject: Re: applyhook
To: KMP@MIT-MC.ARPA
cc: common-lisp@SU-AI.ARPA, WVANROGGEN@DEC-MARLBORO.ARPA
In-Reply-To: Message from "Kent M Pitman <KMP @ MIT-MC>" of Thu 6 Sep 84 18:10:00-EDT
Actually, I hadn't thought about the potential ambiguity of which
environment would be passed to the apply hook function; I had just
assumed that it would be the same as that passed to the eval hook
function immediately before.
It seems to me that the purpose of applyhook is to allow one to
examine the actual function and the actual arguments it's about to
be applied to. (I suppose you could get the effect of the applyhook
by using the evalhook and simulating the evaluator--but that's what
this mechanism should help avoid.) It's a lot easier to examine
the environment of the function when it is handed to you. On the other
hand you could argue that any debugging facility will always use both
evalhook and applyhook simultaneously, but that shouldn't be necessary.
---Walter
-------
∂10-Sep-84 0024 GSB@MIT-MC applyhook and environments
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Sep 84 00:23:33 PDT
Date: 10 September 1984 03:24-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: applyhook and environments
To: Common-Lisp @ SU-AI
I think we've safely established that in order to just function
properly, APPLYHOOK (and therefore the value of *APPLYHOOK*) does
not need to be given an environment argument.
As someone said, it makes no sense to pass one environment because
there are two involved. To me, that means we should pass BOTH
environments. After all, one of the purposes of having this is for
debugging, from user code. If we did not want this we wouldn't have
defined the hooks, just specified the existence of STEP like we have
TRACE. *APPLYHOOK* should be given TWO environments: one is the
current environment (as of when the hook is invoked -- like that given
to *evalhook*). The other is an environment object gleaned from the
function being applied. This is so that *applyhook* can examine
either one. Possibly in the case of compiled or globally defined
functions, the function-environment argument will be NIL, of course.
So, what i propose is this:
*APPLYHOOK* gets called on 4 arguments:
(1) the function being applied
(2) the list of arguments
(3) the environment of the function
(4) the current environment.
APPLYHOOK takes only arguments of the function, arguments, evalhookfn,
and applyhookfn. No environment argument at all -- the function
carries the environment with it. Evaluation of a lambda combination
((lambda ...) ...) passes a function made (as if) by evaluating
(function (lambda ...)).
The function-environment argument to *applyhook* is deliberately
redundant with the environment carried by the function, so that it may
be an environment object just like the current-environment argument,
and thus examined/whatever similarly.
I feel fairly strongly that to not pass these environments to
*applyhook* just because it looks now like we can get away with it
will unnecessarily restrict any sort of debugging extensions in the
future. And even within the present CL definition user code can do
things with them by passing them to EVAL.
∂11-Sep-84 1236 RPG common-lisp mailing list
∂11-Sep-84 1231 hpfclp!hpfcdcm!dcm@csnet-relay.csnet common-lisp mailing list
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Sep 84 12:31:28 PDT
Received: From hplabs.csnet by csnet-relay; 11 Sep 84 13:00 EDT
Date: Tue, 11 Sep 84 01:18:44 pdt
From: hpfclp!hpfcdcm!dcm%hplabs.csnet@csnet-relay.arpa
MMDF-Warning: Parse error in preceeding line at csnet-relay.arpa
Received: by HP-VENUS id AA04507; Tue, 11 Sep 84 01:18:44 pdt
Message-Id: <8409110818.AA04507@HP-VENUS>
To: hpfclp!hplabs!RPG@su-ai.arpa
Subject: common-lisp mailing list
Source-Info: From (or Sender) name not authenticated.
The feed from hpfclp!clisp into our internal notes system is now
working well. You may remove myself and Roger Ison from the
common-lisp mailing list as we will read the postings on our
notes system.
Thank you for you time in setting up the mail forwarding.
Dave Matthews
Hewlett-Packard Company, Fort Collins Systems Division
1-[303]-226-[3800]x2201; uucp: [hplabs,ihnp4]!hpfcla!dcm
∂12-Sep-84 0824 Moon@SCRC-STONY-BROOK.ARPA [Postmaster at SCRC-STONY-BROOK: Unable to deliver letter]
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 12 Sep 84 08:23:20 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 87488; Mon 10-Sep-84 14:35:22-EDT
Date: Mon, 10 Sep 84 14:35 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: [Postmaster at SCRC-STONY-BROOK: Unable to deliver letter]
To: Common-Lisp@SU-AI.ARPA
Message-ID: <840910143505.4.MOON@EUPHRATES.SCRC.Symbolics>
No one but KMP saw this message the first time, which may have made
for a mysterious-looking conversation. Hopefully it will go through
this time.
Date: Thu, 6 Sep 84 22:36 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: More (unrelated) EVALHOOK issues
To: Kent M Pitman <KMP@MIT-DM.ARPA>
cc: Common-Lisp@SU-AI.ARPA
In-Reply-To: The message of 6 Sep 84 18:16-EDT from Kent M Pitman <KMP at MIT-MC>
Message-ID: <840906223648.7.MOON@EUPHRATES.SCRC.Symbolics>
Date: 6 September 1984 18:16-EDT
From: Kent M Pitman <KMP @ MIT-MC>
While I'm thinking about it (something I should have brought up ages ago,
but it might as well at least be on the books)...
There's a problem with EVALHOOK in that it really wants to pass a locative
to the piece of code that's being EVAL'd. Consider the problem of a
display-oriented stepper, trying to evaluate:
(LAMBDA (X) (+ X X))
when EVALHOOK traps on evaluating X, how can you know which X you are
evaluating so as to highlight it. If you think it's fair to assume that
the lexically first X is the one that leads you there, consider:
(LAMBDA (X Y) (COND ((FOO) X) (T (+ X Y))))
It would have been nice if we had made it so the form passed in was a
list whose CAR was the form to be evaluated rather than the form itself.
That way, in the first example above, EVALHOOK could see
(X X)
and in the second, (X). Or perhaps that could be passed in as an extra
arg, being NIL when there was no locative available.
This shortcoming in the info provided by EVALHOOK has come up in
several stepper projects at MIT, and I should have mentioned it before,
but it should be thought about when time for revisions comes along.
I don't see why the user hook function can't maintain its own evaluation
stack, back which it can look. In general, of course, this requires it
to understand special forms. Your scheme, on the other hand, would require
EVAL to be completely remodularized, since it does not currently receive
the arguments it would need to compute the information you want in any
system I know of.
∂12-Sep-84 2309 GS70@CMU-CS-A.ARPA German -> English translator wanted
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 12 Sep 84 23:08:58 PDT
Date: 13 Sep 84 0159 EDT (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: common-lisp@SU-AI.ARPA
Subject: German -> English translator wanted
Herbert Stoyan has written a textbook on LISP in German,
and would like to know whether anyone out there would be
interested in undertaking a translation to English for
publication.
--Guy
∂13-Sep-84 1035 STEELE@TL-20A.ARPA
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 10:35:08 PDT
Received: ID <STEELE@TL-20A.ARPA>; Thu 13 Sep 84 13:37:57-EDT
Date: Thu 13 Sep 84 13:37:51-EDT
From: STEELE@TL-20A.ARPA
To: common-lisp@SU-AI.ARPA
The definitions of characters and strings in Common Lisp assume the
English language and lexicographic ordering. Do you contemplate any
changes to the definition to allow it to work better with other
natural languages? Are you aware of any Lisp implementations which
have addressed this issue?
Thanks,
Kathy Kwinn
There are three issues I can think of here offhand. One is that certain
alphabets contain extra (or different) letters, such as the Scandinavian
slashed-O and AE ligature. Common LISP allows an implementation to
extend the character set, and some of the extra characters may be
alphabetic. Such extra characters may be of type string-char as well.
So these should fit in nicely with the current definitions of such
functions and alpha-char-p and string-capitalize. The primary difficulty
here is that if one uses the standard ASCII code national variants,
these extra letters use ASCII codes normally used in America for "[",
"]", and so on, which are required standard Common LISP characters.
The second issue is accents, such as the accents acute and grave, the
circumflex, the cedilla, the umlaut, and so on. These cause difficulties
no matter how you look at it, especially in string-capitalize, and Common
LISP currently does not address these at all. (As noted in the manual,
these cause problems in English, too: (string-capitalize "don't") =>
"Don'T", not "Don't".)
The third issue is lexicographic ordering. The Common LISP ordering is
actually relatively loose. I believe that lexicographic ordering for
European languages is already difficult even using ASCII because of
accents, extra letters, and special rules (such as "ch" being considered
a single letter for ordering purposes in Spanish dictionaries). Common
LISP does not solve these problems, but is no worse than existing
practice.
--Guy
-------
∂13-Sep-84 1822 BSG@SCRC-STONY-BROOK.ARPA Sequence function predicate arg order
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 18:22:27 PDT
Received: from SCRC-CONCORD by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 88063; Tue 11-Sep-84 09:16:39-EDT
Date: Tue, 11 Sep 84 09:18 EDT
From: "Bernard S. Greenberg" <BSG@SCRC-RIVERSIDE.ARPA>
Subject: Sequence function predicate arg order
To: Common-Lisp@SU-AI.ARPA
Supersedes: <840907153454.7.BSG@CONCORD.SCRC.Symbolics>
Message-ID: <840911091813.0.BSG@CONCORD.SCRC.Symbolics>
Our mailer just returned this as never having gotten to COMMON-LISP.
I don't know if Moon's reply made it either:
-----------
The following issue was encountered today by David Andre. He wanted
to find the position of first element in a string which was not an element of a list
he had in hand. This is Zetalisp's STRING-SEARCH-NOT-SET. The generic
sequence searcher in Common Lisp, the only one that exist, is
POSITION.
POSITION item sequence &key :test-not .....
So he would have given #'MEMBER as :test-not, except that the language
specifies that MEMBER will be called on arguments in the order of
the representing objects in the original argument list, which is wrong
for this application.
The strict definition of argument order for tests of :test/:test-not is
of course necessary for these functions to be useful with non-symmetric
tests. Unfortunately, some tests cannot thus be used.
Oops.
Possible outcomes:
1. Magic keyword to sequence functions to reverse test arg order? ECCH!
2. More string-specific primitives.
3. Maybe he should have said :test #'(lambda (x y)(member y x)).
∂13-Sep-84 1825 Moon@SCRC-STONY-BROOK.ARPA Sequence function predicate arg order
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 13 Sep 84 18:25:33 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 88224; Tue 11-Sep-84 12:54:12-EDT
Redistributed-date: Tue, 11 Sep 84 12:53 EDT
Redistributed-to: Common-Lisp@SU-AI.ARPA
Date: Fri, 7 Sep 84 16:18 EDT
From: Moon@SCRC-STONY-BROOK.ARPA
Subject: Sequence function predicate arg order
To: BSG@SCRC-STONY-BROOK.ARPA
cc: Common-Lisp@SU-AI.ARPA, bug-clcp@SCRC-STONY-BROOK.ARPA,
dla@SCRC-STONY-BROOK.ARPA
In-Reply-To: <840907153454.7.BSG@CONCORD.SCRC.Symbolics>
Message-ID: <840907161802.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: Friday, 7 September 1984, 15:34-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
The following issue was encountered today by David Andre. He wanted
to find the position of first element in a string which was not an element of a list
he had in hand....
Possible outcomes:
1. Magic keyword to sequence functions to reverse test arg order? ECCH!
2. More string-specific primitives.
3. Maybe he should have said :test #'(lambda (x y)(member y x)).
Among your alternatives, I'd prefer #3, i.e. write
(position list sequence :test-not #'(lambda (x y) (member y x)))
I would actually write
(position-if-not #'(lambda (item) (member item list)) sequence)
∂14-Sep-84 1313 DLW@SCRC-STONY-BROOK.ARPA External symbols and inheritance
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 13:13:05 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 91319; Fri 14-Sep-84 16:15:07-EDT
Date: Fri, 14 Sep 84 16:14 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Subject: External symbols and inheritance
To: common-lisp@SU-AI.ARPA
Message-ID: <840914161436.7.DLW@CHICOPEE.SCRC.Symbolics>
If package A uses package B, and package B exports the symbol FOO, then
is a reference to A:FOO supposed to get that symbol, or be an error?
∂14-Sep-84 1315 fateman%ucbdali@Berkeley several questions, some trivial
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 13:15:05 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.31)
id AA22328; Fri, 14 Sep 84 09:40:08 pdt
Received: by ucbdali.ARPA (4.24/4.38)
id AA08645; Fri, 14 Sep 84 09:40:12 pdt
Date: Fri, 14 Sep 84 09:40:12 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8409141640.AA08645@ucbdali.ARPA>
To: common-lisp@su-ai
Subject: several questions, some trivial
Missing from the index of the CL manual:
"argument"
"rest" as in "&rest" and &others
The issue of identical semantics for compiled and interpreted programs
has been touted as an important step forward.
If I understand the manual, (nearly) identical semantics
pertain to CORRECT programs only.
If there are declarations, those too must be CORRECT declarations.
If we look at Maclisp with (declare (special t)), is it not the
case that (nearly) identical semantics are used for the interpreter
and compiler, given CORRECT programs?
In Maclisp, if there are declarations which are correct, are not the semantics
still (nearly) identical?
(I suppose "nearly" because one could write self-modifying functions and
other monstrosities in CL or Maclisp.)
Since most programs are, for most of their lives, "incorrect", aren't we
open to the accusation of missing the main point here?
Leaving car of an atom as undefined (e.g.) means that
compiled and interpreted versions of the same program can do different
things. This can be just as subtle as dynamic/lexical binding.
∂14-Sep-84 1634 RAM@CMU-CS-C.ARPA External symbols and inheritance
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 16:34:40 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 14 Sep 84 19:31:43-EDT
Date: Fri, 14 Sep 1984 19:31 EDT
Message-ID: <RAM.12047608790.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: External symbols and inheritance
In-reply-to: Msg of 14 Sep 1984 16:14-EDT from Daniel L. Weinreb <DLW at SCRC-QUABBIN.ARPA>
It seems fairly clear to me that it is an error. The single-colon
notation referrs to an external symbol in the named package.
Use-Package makes the external symbols of the used package available as
internal symbols. Externalness is a property of how the symbol is
available in the package rather than an inherent attribute of the
symbol.
The semantics of the package system are fairly straightforward
when thought of in terms of the obvious implementation of maintaining
separate hashtables for each package and searching used packages to
find inherited symbols. This implementation seems to be working quite
well for Spice Lisp, and I would suggest that implementors try it to
see whether Intern is a performance bottleneck before attempting
a "better" algorithm.
Rob
∂15-Sep-84 1557 FAHLMAN@CMU-CS-C.ARPA External symbols and inheritance
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Sep 84 15:57:20 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 15 Sep 84 18:54:30-EDT
Date: Sat, 15 Sep 1984 18:54 EDT
Message-ID: <FAHLMAN.12047864151.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>, common-lisp@SU-AI.ARPA
Subject: External symbols and inheritance
If package A uses package B, and package B exports the symbol FOO, then
is a reference to A:FOO supposed to get that symbol, or be an error?
I agree with Rob Maclachlan on this: the symbol FOO is internal in
package A, so A:FOO is an error. This behavior is clearly prescribed by
the last full paragraph on page 177 of the manual, is it not? Or have
we misunderstood your question?
-- Scott
∂15-Sep-84 1633 FAHLMAN@CMU-CS-C.ARPA several questions, some trivial
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 15 Sep 84 16:32:58 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 15 Sep 84 19:30:59-EDT
Date: Sat, 15 Sep 1984 19:30 EDT
Message-ID: <FAHLMAN.12047870802.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: several questions, some trivial
In-reply-to: Msg of 14 Sep 1984 12:40-EDT from fateman%ucbdali at Berkeley (Richard Fateman)
If we look at Maclisp with (declare (special t)), is it not the
case that (nearly) identical semantics are used for the interpreter
and compiler, given CORRECT programs?
Sure, there are lots of special cases in which Maclisp's interpreted
behavior matches its compiled behavior. The point is that few users
want all of their variables to be special and that a LOT of Maclisp
programs break when you compile them because of the different treatment
of special and local variables. In Common Lisp, this big difference
between compiled and interpreted code goes away, along with some lesser
problems. That's what's being touted. I don't think this clean-up is
of revolutionary importance, but it certainly eliminates a long-standing
embarassment and a source of considerable confusion for new users. If
people are touting this as a great advance in the theory and practice of
programming, then they're guilty of exaggeration, but it is one small
thing that Common Lisp does better than most earlier Lisps.
Since most programs are, for most of their lives, "incorrect", aren't we
open to the accusation of missing the main point here?
I disagree with your premise. Most of my programs, for most of their
lives, are correct, at least if by program you mean "Lisp function".
Obviously, any sufficiently large system will have a couple of bugs in
it somewhere, even after it is tested and released, but the point is
that compilation does not normally change the program's behavior except
at these few points, and probably only at a small minority of those.
The new thing is that we have made it an explicit goal of the language
design (though not the only goal) that compilation should not change
behavior, and we have made a serious attempt to fulfill this goal. In
particular, we eliminated the single largest violation of this principle
that is present in most earlier Lisps. As you say, a user can still
screw himself by doing really perverse things like redefining CAR at
runtime, but I don't think I've ever seen a user screw himself by
accident when he compiled a Common Lisp program, and this used to happen
all the time in Maclisp and Franzlisp.
-- Scott
∂18-Sep-84 1044 joseph@SCRC-STONY-BROOK.ARPA Unable to deliver letter
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Sep 84 10:43:49 PDT
Received: from SCRC-HARLEM by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 92685; Tue 18-Sep-84 09:33:05-EDT
Date: Monday, 10 September 1984, 17:11-EDT
From: Postmaster at SCRC-QUABBIN
Subject: Unable to deliver letter
To: Moon at SCRC-QUABBIN
Resent-To: "common-lisp@su-ai"@MIT-MC.ARPA
Resent-From: joseph@SCRC-QUABBIN.ARPA
Resent-Date: Tue, 18 Sep 84 09:32 EDT
Resent-Message-ID: <840918093215.9.JOSEPH@HARLEM.SCRC.Symbolics>
Unable to deliver letter to the following recipient:
Common-Lisp at SU-AI: Host not responding.
----- Text of letter follows -----
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 79561; Fri 7-Sep-84 16:17:53-EDT
Date: Fri, 7 Sep 84 16:18 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Sequence function predicate arg order
To: "Bernard S. Greenberg" <BSG@SCRC-STONY-BROOK.ARPA>
cc: Common-Lisp@SU-AI.ARPA, bug-clcp@SCRC-STONY-BROOK.ARPA,
dla@SCRC-STONY-BROOK.ARPA
In-Reply-To: <840907153454.7.BSG@CONCORD.SCRC.Symbolics>
Message-ID: <840907161802.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: Friday, 7 September 1984, 15:34-EDT
From: Bernard S. Greenberg <BSG at SCRC-TENEX>
The following issue was encountered today by David Andre. He wanted
to find the position of first element in a string which was not an element of a list
he had in hand....
Possible outcomes:
1. Magic keyword to sequence functions to reverse test arg order? ECCH!
2. More string-specific primitives.
3. Maybe he should have said :test #'(lambda (x y)(member y x)).
Among your alternatives, I'd prefer #3, i.e. write
(position list sequence :test-not #'(lambda (x y) (member y x)))
I would actually write
(position-if-not #'(lambda (item) (member item list)) sequence)
∂20-Sep-84 1057 WHOLEY@CMU-CS-C.ARPA As long as we're sending out songs...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Sep 84 10:57:07 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 20 Sep 84 13:55:57-EDT
Date: Thu, 20 Sep 1984 13:55 EDT
Message-ID: <WHOLEY.12049120520.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: As long as we're sending out songs...
Common LISP
(to the tune of Dylan's "Maggie's Farm")
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
See, it was spawned from MACLISP,
And then they threw in Scheme,
And now everybody's made it
"just a little" short of clean.
The language specification is insane.
I ain't gonna hack on Guy Steele's LISP no more,
I ain't gonna hack on Guy Steele's LISP no more.
When you mail him a question,
And then wait for a reply,
Well you can sit for weeks now,
And begin to think he's died.
His MAIL.TXT is one great big black hole.
I ain't gonna hack on Fahlman's LISP no more,
I ain't gonna hack on Fahlman's LISP no more.
Well he gives you an X-1, [1]
And he puts you on a Perq,
And he asks you with a grin,
"Hey son, how much can you work?"
If I reboot one more time I'll lose my brain.
I ain't gonna hack on Dave Moon's LISP no more,
I ain't gonna hack on Dave Moon's LISP no more.
We had a simple SETF,
But it choked on LDB.
So Lunar Dave done fixed it:
Go look at page eighty three. [2]
The Gang of Five they didn't take a poll. [3]
I ain't gonna hack on Common LISP no more,
I ain't gonna hack on Common LISP no more.
With its tons of sequence functions,
And its lexical scoping,
I've now begun to like it,
But the users are moping:
"Without EXPLODE my life is full of pain." [4]
(harmonica and fade)
-------------------------------------------------------------------------------
Notes:
1. An "X-1" is the key required to access CMU CSD facilities.
2. 83 was the page number describing Define-Setf-Method in the Mary Poppins
edition. It's probably changed.
3. There aren't verses for Weinreb and Gabriel because the orginal song has
only 3 verses about people. I couldn't think of anything clever to say
about them, anyway.
4. Yes, we really had users complaining about the lack of EXPLODE and friends.
No offense is intended towards any people named or unnamed.
∂20-Sep-84 1116 WHOLEY@CMU-CS-C.ARPA Sorry...
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 20 Sep 84 11:13:52 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 20 Sep 84 14:12:44-EDT
Date: Thu, 20 Sep 1984 14:12 EDT
Message-ID: <WHOLEY.12049123581.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Sorry...
Oops, I saw Common Lisp songs flying by on Info-Cobol, but sent mine to the
Common-Lisp mailing list by mistake. Freudian slip indeed. Sorry to take such
time on a ultra-high-bandwidth, very serious language-design forum.
∂22-Sep-84 0811 FAHLMAN@CMU-CS-C.ARPA Getting organized
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 08:11:02 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 22 Sep 84 11:12:02-EDT
Date: Sat, 22 Sep 1984 11:11 EDT
Message-ID: <FAHLMAN.12049614982.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA
Subject: Getting organized
OK, we got elected for another six months and now we've got some work to
do. The first order of business, I guess, is to elect ourselves a
chairman. I guess this would be someone with no particular powers, but
who would combine the role of what we called "moderator" before (quick
responses to queries and keeping those things rolling that need to be
rolling) with some minor duties as spokesman for the group. I'm hoping
that whoever is moderator, he'll end up doing only slightly more work
than the rest of us, and that the burden of resolving old issues,
setting up mailing lists, taking polls on new issues, interacting with
DARPA people on the charter, and so on can be shared by others within
the group.
I am willing to do this for the next few months, at least. I think I'll
have the time to give fast turn-around on mail and to do some of the
other stuff (but not EVERYTHING that we as a group have to get done).
I'd rather spend that time doing AI, so if we have any other candidates
who are willing and able to commit the necessary time, I will gladly
step aside. Do we?
-- Scott
∂22-Sep-84 1104 RPG Chairman
To: quinquevirate@SU-AI.ARPA
I believe Scott will do an excellent job as chairman. If he feels that it
is taking up too much of his time, I would be happy (?) to step in to keep
things rolling. I am currently setting up all the mailing lists for the
subgroups and getting accounts for the non-ARPA folks. I expect I'll be
sending out the first mailings to those lists tomorrow - it is a larger
database problem than the common-lisp mailing list.
As you all know or suspect, Xerox and DARPA got together at Monterey and
discussed Xerox's problems. I met with Xerox before the meeting and sent
the following report to Ohlander and Squires:
``I talked to Beau Sheil at Xerox PARC last wednesday (Sept 5) at his
request. The topic of discussion was how to maintain the existing Xerox
customer base while shifting towards a more standard Lisp. Sheil expressed
several concerns.
``First was that Xerox did not have the resources to join in the Common
Lisp effort at the start, nor did it have the foresight to do so.
``Second, the existing InterLisp user base ought not be left behind, as
would be the case if Xerox were to abandon InterLisp in favor of Common
Lisp.
``Third, Sheil did not think that both InterLisp and Common Lisp could be
supported by Xerox at the same time.
``Fourth, Sheil thought that the InterLisp file system style (that is,
files are ignorable side effects of user activity) and the other InterLisp
user-interface tools could not be supported easily within Common Lisp.
``Fifth, Common Lisp looks too much like the Lisp sold by Xerox's
competitor.
``And sixth, there is too much existing InterLisp code to easily transport
to Common Lisp.
``Sheil proposed the following solution: A standards committee should be
set up to explore a subset of Common Lisp which would be easily
supportable by Xerox and which would not burden their current user base. I
believe his intention was that this subset also would be moved towards
InterLisp. Therefore, I believe his proposal is to compromise between
InterLisp and a subset of Common Lisp.
``My views on this proposal are mixed. First, I think that, even ignoring
DARPA's position, the commercial world is moving with enough force to make
Common Lisp a de facto standard. Second, on the other hand, I think that
he and Xerox deserve a fair hearing on their views. If the compromise was
that a subset of Common Lisp were the DARPA standard, and if that subset
could easily be absorbed by Xerox, then I think that that is worthy of
consideration.''
The statements in that message reflect my own opinions only, and I was not
acting as a representative of any of: the Common Lisp Committee, Stanford
University, and Lucid.
As you know, I went to dinner with Ohlander, Squires, and Machado tuesday
evening in Monterey; the topic of discussion was, primarily, Xerox and
Common Lisp. Squires and Ohlander want to see a dialogue between the
Common Lisp people and Xerox. We settled on the following plan, which I
hope you will not find objectionable:
There will be 4 tiers of dialogue. I will meet with Sheil and Xerox over a
period of a few weeks to discuss how Xerox can come to support a community
standard which is essentially Common Lisp. I anticipate that they will
propose a subset of Common Lisp and of InterLisp which can be either
unified or translated between. My job will be to test their sincerity, to
judge their willingness to move to Common Lisp over a period of time, to
propose means of accomplishing that end, and to provide a political buffer
between the rest of you and Xerox.
In particular, I believe that the higher management of Xerox sees the
writing on the wall, and they want to move towards the direction that that
handwriting points, but they want to save face. Or, at least, the lower
management wants to save face with the higher management. Token compromise
- where Common Lisp moves a bit and InterLisp moves a lot - is my view of
what may be what's needed.
If I test the waters, then you all are spared that job, and any mistakes I
make are Gabriel's mistakes and not the Common Lisp Committee's.
The next step happens if Xerox acts reasonably (no comments, please).
Scott and Guy will be asked to enter the picture. If that step succeeds,
then all of us will meet with them or discuss matters in the usual way -
as a proposal on which we all comment.
Finally - the fourth step - we will pose things to the entire Common Lisp
group.
The best case would be to token-compromise on a subset, back up the
compromises into Common Lisp, and for Xerox to move towards that over the
years. I can imagine ways that DARPA could help Xerox do that.
Regardless of the outcome of these meetings, the political gesture of a
negotiation helps DARPA if it has to make the hard decision to require
Common Lisp, helps the public image of Common Lisp, and saves Xerox's
face.
I think we ought to restrict discussion of this matter to the 5 of us
for a while, but I welcome your initial comments on the situation - I
want to represent the feelings of this group as best as I can when
I meet with Xerox.
-rpg-
∂22-Sep-84 1345 FAHLMAN@CMU-CS-C.ARPA Xerox
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 13:45:03 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 22 Sep 84 16:46:00-EDT
Date: Sat, 22 Sep 1984 16:45 EDT
Message-ID: <FAHLMAN.12049675771.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA
Subject: Xerox
In-reply-to: Msg of 22 Sep 1984 14:04-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
A few opinions of my own on Xerox, for what they may be worth:
As Gabriel notes, Common Lisp is going to be a de facto standard whether
Xerox likes it or not. They may or may not be able to stop DARPA from
requiring Common Lisp anytime soon, but that's all they can do. They've
lost, and they know it as well as we do. This means that they can't
MAKE us compromise on anything we don't want to, and we should keep that
in mind: if it comes down to an all-out battle, they lose. It also
means that we can afford to be magnanimous victors and do whatever we
can to help them save face, make life easy for their existing users,
etc. Even if they get a bit nasty, we should refuse to reciprocate; let
the world see that all of the pettiness is coming from their side. But
without getting nasty, we should be firm.
On the issue of changes to Common Lisp itself, I think that they have
the same right to propose changes as anyone else in the Common Lisp
community. If there's some little more-or-less compatible change (Sheil
mumbled something about character macros as an example) that we can make
that would make it easier for Interlisp people to cope with the
transition, we should seriously consider this. But I for one am not
interested in changing Common Lisp extensively, this late in the game,
if that is the price for bringing Xerox aboard officially. They will
represent this as "opening things up to the Interlisp community", but of
course the Interlisp users will mostly be coming over anyway, sooner or
later, so we're really talking about Xerox itself.
This intransigence only applies to the issue of changing Common Lisp
itself, and perhaps to the issue of creating a subset that would tend to
blur the definition of "real" Common Lisp. If there's some coherent way
to come up with a "transitional" subset that will run in both
environments, we should support that. I doubt that this is possible,
however. The differences in scoping, for example, only make trouble in
a few places during a port, but I know of no way to paper them over,
except by specifying that the code must also run in Common Lisp, which
begs the question. Still, if they think they can pull this feat off,
they should have our full support. Of course, what DARPA should require
is that software for Strategic Computing (or whatever) can be written
either in REAL Common Lisp or in this subset of Interlisp which runs in
Common Lisp, not that everyone live in this subset.
I think a sort of litmus test of Xerox's sincerity is whether they are
willing to allow someone to offer a REAL Common Lisp for the
Dandelion/tiger or whether they want to force people using their
hardware to stick with Interlisp by making Common Lisp unavailable. If
the latter, then anything they say about wanting to make things easy for
their users is a lie, and they should not expect us to have any more
concern for their users than they have. If resources to support yet
another Lisp are the problem, I can think of several organizations that
would be interested in writing and supporting a Common Lisp to run on
top of Xerox's development environment -- no cost to Xerox except maybe
lost interlisp sales, and probably a big boost for their hardware sales,
since users wouldn't have to worry about which way things are going to
go.
-- Scott
∂22-Sep-84 1700 AS%hp-hulk.csnet@csnet-relay.arpa more questions
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 16:57:15 PDT
Received: From hplabs.csnet by csnet-relay; 22 Sep 84 19:37 EDT
Received: by HP-VENUS id AA27329; Thu, 20 Sep 84 15:51:02 pdt
Message-Id: <8409202251.AA27329@HP-VENUS>
Date: 20 Sep 1984 1551-PDT
From: AS%hplabs.csnet@csnet-relay.arpa
Subject: more questions
To: Common-Lisp@su-ai.arpa
Cc: AS@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
I have not been able to find (clear) answers to these questions in the manual.
Clarification is requested.
* What happens if the type name in a DEFTYPE or DEFSTRUCT is the name of an
existing type (either primitive or user-defined)? Is redefinition allowed or
prohibited, and in what circumstances?
* What happens in a DEFSTRUCT if two slots have the same name? Is it an
error, or is the extra slot definition ignored?
* What happens in a DEFSTRUCT if a slot has the same name as an inherited
slot? Is it an error, is the new slot definition ignored, are the two slot
definitions "merged", or does the new slot "shadow" the inherited one?
* The definition of *PRINT-CIRCLE* only says that the printer "will endeavor"
to detect cycles. How hard must the printer try? Is an implementation that
totally ignores *PRINT-CIRCLE* correct?
* Are cycles involving structures (DEFSTRUCTs) handled by *PRINT-CIRCLE*? If
so, how do DEFSTRUCT :print-functions interact with *PRINT-CIRCLE*?
* May an implementation impose a fixed upper bound on the length of a symbol
name? If so, is there a minimum such bound? Similar questions can be asked
regarding the sizes of strings, vectors, and arrays, and the possible
interrelationships among such limits. (It is important to make our
assumptions explicit, as an implementor whose background is in conventional
programming languages might not share these assumptions. Ideally, I would
say that no fixed limit other than available free storage can be placed on any
of these sizes.)
* Must (EQ (SYMBOL-NAME 'FOO) (SYMBOL-NAME 'FOO)) be true, or may the function
SYMBOL-NAME return a newly created copy of the name string each time it is
called? (My reading of the definition is that there is a unique print name
string for each symbol and that SYMBOL-NAME returns it; others have come to a
different conclusion.)
* DEFSTRUCT does not create named functions for altering components of a
structure, but instead arranges to make SETF do "the right thing". Does this
mean that the user cannot TRACE structure alteration or control the use of
inline code for structure alteration (which might affect how the debugger
describes the state of a computation)? (The general question: is not having
named update functions for generalized variables really such a good idea?)
Alan Snyder
snyder%hplabs@csnet-relay
-------
∂22-Sep-84 2135 REM%IMSSS.#Pup@SU-SCORE.ARPA Common-LISP book questions and errors?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 21:35:05 PDT
Received: from IMSSS by Score with Pup; Sat 22 Sep 84 21:32:19-PDT
Date: 22 Sep 1984 2134-PDT
From: Rem@IMSSS
Subject: Common-LISP book questions and errors?
To: COMMON-LISP%SU-AI@SCORE
I'm working on a project that might start implementing Common-LISP soon.
I have a number of questions and some errata from the Common-LISP book.
Is this the correct mailing list for such matters? Is there a database
of already-answered questions and already-found errata that I should
consult to avoid duplication? Are there individuals I should ask certain
kinds of questions to and report errata to instead of dumping them on
this whole mailing list, or should everything be reported to the whole
mailing list so that everybody gets to see everything?
Replies to REM%IMSSS@SCORE.ARPA or if that doesn't work then REM@MIT-MC.ARPA
or REM@SU-AI.ARPA (or if you happen to be on SCORE or IMSSS you can use
REM@IMSSS or just REM respectively) -- when name domains are implemented
this may be simpler.
-------
∂23-Sep-84 0503 RAM@CMU-CS-C.ARPA more questions
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 05:02:49 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sun 23 Sep 84 08:03:39-EDT
Date: Sun, 23 Sep 1984 08:03 EDT
Message-ID: <RAM.12049842825.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: AS%hplabs.csnet@CSNET-RELAY.ARPA
Cc: AS@CSNET-RELAY.ARPA, Common-Lisp@SU-AI.ARPA
Subject: more questions
In-reply-to: Msg of 20 Sep 1984 18:51-EDT from AS%hplabs.csnet at csnet-relay.arpa
Date: Thursday, 20 September 1984 18:51-EDT
From: AS%hplabs.csnet at csnet-relay.arpa
To: Common-Lisp at su-ai.arpa
cc: AS at csnet-relay.arpa
Re: more questions
I have not been able to find (clear) answers to these questions in
the manual. Clarification is requested.
* What happens if the type name in a DEFTYPE or DEFSTRUCT is the
name of an existing type (either primitive or user-defined)? Is
redefinition allowed or prohibited, and in what circumstances?
* What happens in a DEFSTRUCT if two slots have the same name? Is
it an error, or is the extra slot definition ignored?
* What happens in a DEFSTRUCT if a slot has the same name as an
inherited slot? Is it an error, is the new slot definition
ignored, are the two slot definitions "merged", or does the new
slot "shadow" the inherited one?
I would say that except for redefining a DEFTYPE with another
DEFTYPE, all of these should be errors. Permitting any of these things
would add complexity without adding any power.
* The definition of *PRINT-CIRCLE* only says that the printer
"will endeavor" to detect cycles. How hard must the printer try?
Is an implementation that totally ignores *PRINT-CIRCLE* correct?
* Are cycles involving structures (DEFSTRUCTs) handled by
*PRINT-CIRCLE*? If so, how do DEFSTRUCT :print-functions interact
with *PRINT-CIRCLE*?
It is clearly possible, and not even very difficult, to detect
cycles, thus I see not reason why the printer shouldn't do it. All
you have to do is enter every object printed in a hashtable, clearing
the hashtable at every top-level call to Print. Structure print
functions add no substantial degree of complexity to this. Print
simply needs to detect when it has been called from a print function,
and not clear the hashtable in that case. Of course if the
print-function itself breaks due to circularity in the structure,
there is nothing that can be done.
* May an implementation impose a fixed upper bound on the length
of a symbol name? If so, is there a minimum such bound? Similar
questions can be asked regarding the sizes of strings, vectors,
and arrays, and the possible interrelationships among such limits.
(It is important to make our assumptions explicit, as an
implementor whose background is in conventional programming
languages might not share these assumptions. Ideally, I would say
that no fixed limit other than available free storage can be
placed on any of these sizes.)
There is Array-Total-Size-Limit, whose minimum value is 1024. Most
likely, the real limit on total size will be different for different
types of arrays, but this limit should be the minimum. Since for
symbol functions no type specification is given for the pname other
than that is a string, then any legal string must work. This would
mean that the least limit on pname length would be 1024.
* Must (EQ (SYMBOL-NAME 'FOO) (SYMBOL-NAME 'FOO)) be true, or may
the function SYMBOL-NAME return a newly created copy of the name
string each time it is called? (My reading of the definition is
that there is a unique print name string for each symbol and that
SYMBOL-NAME returns it; others have come to a different
conclusion.)
I would say that this should be left up to the implementation, since
requiring this would constrain the implementor without buying any power.
* DEFSTRUCT does not create named functions for altering
components of a structure, but instead arranges to make SETF do
"the right thing". Does this mean that the user cannot TRACE
structure alteration or control the use of inline code for
structure alteration (which might affect how the debugger
describes the state of a computation)? (The general question: is
not having named update functions for generalized variables really
such a good idea?)
I would say that it is currently clearly the case that setf methods
cannot be traced. If function specifications are added to the
language, then they could be used to fix this problem. Since a setf
method has in the general case the semantics of a macro, it doesn't
seem possible to declare a setf method not inline.
Rob
∂23-Sep-84 0816 FAHLMAN@CMU-CS-C.ARPA Common-LISP book questions and errors?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 08:15:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 23 Sep 84 11:16:10-EDT
Date: Sun, 23 Sep 1984 11:16 EDT
Message-ID: <FAHLMAN.12049877874.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem%IMSSS@SU-SCORE.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Common-LISP book questions and errors?
In-reply-to: Msg of 23 Sep 1984 00:34-EDT from Rem at IMSSS
Right now, Common Lisp at SU-AI is indeed the proper mailing list for
implemenation questions. Sometime soon, we plan to split this into
separate lists for designers/implementors and for the user community.
We also plan very soon to set up an online file where
previously-answered questions and their answers (plus any discussion)
will live, as well as a file containing all the current differences
between the manual and TRUTH. This stuff will be announced on Common
Lisp when it is ready.
In general, any questions should be sent to the whole mailing list,
since such issues are likely to be of interest to the whole community,
and any answer received privately from just one individual will not be
reliable or official. Of course, if the issue is merely a typo in the
manual with no semantic content, mail to STEELE@CMU-CS-C will suffice.
-- Scott
∂23-Sep-84 1604 RPG Mailing list administrivia
∂23-Sep-84 1334 KMP@MIT-MC Mailing list administrivia
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 13:34:01 PDT
Date: 23 September 1984 16:30-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Mailing list administrivia
To: RPG @ SU-AI
cc: COMMON-LISP-REQUEST @ MIT-MC
Reply-To: COMMON-LISP-REQUEST@MC
I created the following mailing lists on MC:
Full Name Alias Purpose
COMMON-LISP-FORUM CL-FORUM ==> COMMON-LISP-FORUM@SAIL
COMMON-LISP-FORUM-LOCAL none Local distribution.
COMMON-LISP-IMPLEM CL-IMPLEM ==> COMMON-LISP-IMPLEM@SAIL
COMMON-LISP-IMPLEM-LOCAL none Local distribution.
COMMON-LISP-REQUEST CL-REQUEST Local list maintenance.
When you get around to revamping COMMON-LISP@SAIL, please add
COMMON-LISP-FORUM-LOCAL@MC and COMMON-LISP-IMPLEM-LOCAL@MC as
recipients to the revamped lists and send me a list of the people
who should be on those lists (so you can remove them from your
distribution list).
When we really open up these lists to a larger audience, local
redistribution such as this will hopefully keep the mailers involved
from becoming swamped. If for some reason you don't agree and would
rather retain control of either or both of these lists on SAIL,
just let me know and I'll undo these changes. I haven't announced
them anywhere. Also, obviously, the choice of names is still flexible.
-kmp
Your mailing list setup is ok. But change it as follows:
COMMON-LISP-IMPLEM CL-IMPLEM ==> COMMON-LISP-IMPLEMENTATION@SAIL
∂23-Sep-84 1647 RPG Working Groups
To: common-lisp@SU-AI.ARPA
At the Monterey Common Lisp Meeting a number of working groups were
established. They are considering the following topics:
Object-Oriented Programming
Windows
Error handling
Iteration
Graphics
Foreign Function-Call
Subsets
Validation
Charter
Multiprocessing
The Charter working group is to establish the rules for making extensions
to Common Lisp. That is, this group will propose the bureaucratic structure
of Common Lisp for the future.
If you have already received an `Introduction' letter for one of these subgroups,
then you are already in that subgroup. If you did not and believe you ought to
be, please send mail to RPG@SAIL. Also, you should let me know about any other
interested parties who are not already on the COMMON-LISP mailing list.
Later I will be splitting the COMMON-LISP mailing list into a discussion
list and an implementation list. You should tell on which of these you
would like to be. The discussion list is primarily for users and random
discussion, and the implementation list is for implementors and other
interested parties to discuss issues.
-rpg-
∂23-Sep-84 1800 REM%IMSSS.#Pup@SU-SCORE.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 18:00:22 PDT
Received: from IMSSS by Score with Pup; Sun 23 Sep 84 17:51:03-PDT
Date: 23 Sep 1984 1752-PDT
From: Rem@IMSSS
Subject: Questions about specification and possible implementations
To: COMMON-LISP%SU-AI@SCORE
Here's a terse list of major questions I have about Common LISP, with
motivation included in some cases. If any questions are interesting
yet ambiguous, feel free to ask for more info. I tend to be too
verbose with my netmail, so I'm trying to be terse here.
In Common LISP there seems to be a strong dichotomy between functions
(all arguments evaluated before call) and macros&SpecialForms, almost
to the point of forbidding implementors to jump across the barrier.
Yet some functions with all the &OPTIONAL and &KEY arguments may be
difficult or inefficient to implement as true functions, and thus may
be implemented as FEXPRs in the interpretor and MACROs in the
compiler. The question is, what will (FUNCTION foo) do if foo is the
name of a MACRO or FEXPR? It's supposed to be the functional
interpretation of foo, so does it make up a function that calls the
MACRO or FEXPR even though inefficient, or does it totally break down
because there's no functional interpretation for a MACRO or FEXPR? If
(FUNCTION foo) does work, is the result suitable for passing to APPLY
or MAP and does it have the expected semantics as if were really a
function in the first place?
The book says the set of special forms is fixed and no way is provided
to make new ones. But is any way provided to define some of the
special forms from LISP level in the first place, or must all be
handcoded in assembly language or C etc.? Is any way provided to
install bugfixes in special forms by overlaying the old definition
with a new one?
At the front of the chapter on numbers it claims:
(LET ((X Z) (Y Z))
(EQ X Y))
may be false if the value of Z is a number. I can't see a mechanism
for this in any reasonable LISP unless Z is not only presently a
number but has been declared a number and this is compiled code which
represents the value of Z as a machine number instead of a LISP
object, whereas X and Y are undeclared and thus LISP objects, so new
objects must be constructed for X and Y to hold the value Z, and these
new objects won't be EQ to each other. But could somebody who really
knows tell me what the true explanation is?? The book leaves this a
complete mystery.
Minor questions:
In the introductory chapter, the Common-LISP book says semicolon
causes all characters up to eol to be discarded, but doesn't say
whether eol is kept or discarded.
Ditto, doesn't say which characters inside "" are automatically
letterified and which have their usual semantic effects and thus need
explicit letterification to be treated as string text.
Ditto, backslash at end of line does what? (Illegal, quote just the
next character which may be half of a crlf on some systems, quote the
eol token always?)
Ditto, vertical-bar, same questions as for "".
(If above questions are answered elsewhere in manual, need pointer
from intro to where info given?)
When COPY-SYMBOL is done, the pnames will be the same, but will they
be EQ or just EQUAL?
The book doesn't say what (/ 1 0) does. Is it an error, or does it
signal an error, or does it return the ratio of 1/0 as a way of
representing infinity, or what?
If NIL is an element of an assoc list, does this element get skipped
over by ASSOC et al or is it a stop flag?
How are the axis numbers of an array numbered, that is if you
create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0)
return 3 or 7?
-------
∂24-Sep-84 0943 RPG Re: Working Groups
∂23-Sep-84 1704 HEDRICK@RUTGERS.ARPA Re: Working Groups
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 17:02:51 PDT
Date: 23 Sep 84 20:03:21 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Working Groups
To: RPG@SU-AI.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of 23 Sep 84 19:47:00 EDT
Please contact bein@sri-prism about being on the multiprocessing
working group. He will be implementing CL for the Pyramid Unix
system, and I know he is very interested in that topic. (I gave
him a detailed account of the meeting.)
I'm not sure just who is on your list from Rutgers. Certainly
Steiner, Fischer, Josh, and I should be on the implementation
list. Others (if any) should probably be on the users list.
-------
∂24-Sep-84 0947 FAHLMAN@CMU-CS-C.ARPA Online documents
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 09:47:39 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Sep 84 12:46:51-EDT
Date: Mon, 24 Sep 1984 12:46 EDT
Message-ID: <FAHLMAN.12050156523.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: steele@CMU-CS-C.ARPA
Cc: fahlman@CMU-CS-C.ARPA, quinquevirate@SU-AI.ARPA
Subject: Online documents
Guy,
Step one in getting our house in order is to get the archived mail
messages into some more accessible place so that we can all reference
them more easily. Telnetting over to CMUA in order to use RDMAIL is a
process too horrible to continue and since the RDMAIL file format is not
pure ascii (unlike most other mail-file formats), it is very hard to
reference this stuff in any other way or ship it around the net.
Luckily, we've got a lot of space on the PRVA: device on CMUC. I think
the first step should be to break up the behemoth mail file into several
smaller text files and ship them to this area on CMUC. If you do the
first step of this, I'll do the second. If you have the post
publication mail in a file of its own, so much the better.
For now, we can use CMUC as the central repository for online material,
though this may not be a good permanent solution.
I am hoping that we can distribute the work in some reasonable way. The
following might work:
* Coordination of netmail discussions: Fahlman
* Riding herd on the working groups: Gabriel.
* Interface to DARPA on administrative support and related issues: Gabriel.
* Responding to simple queries: all of us, but Fahlman is responsible if
nobody else jumps in.
* Maintaining Archives and Current Truth Document: Steele, with help from
Fahlman as needed.
* Future editions of the book: Steele.
* Sorting through the current backlog of unresolved small issues and proposing
answers (similar to the pre-Flag Day process): Weinreb, assisted by
Steele.
* Work on a few of the major proposals (e.g. Flavors): Moon, Fahlman.
Does that sound OK? Counter proposals?
-- Scott
∂24-Sep-84 0952 RPG Common Lisp groups
∂23-Sep-84 2149 HANDERSON@CMU-CS-C.ARPA Common Lisp groups
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 21:49:03 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 24 Sep 84 00:48:13-EDT
Date: Mon, 24 Sep 1984 00:48 EDT
Message-ID: <HANDERSON.12050025705.BABYL@CMU-CS-C.ARPA>
From: Steven Handerson <Handerson@CMU-CS-C.ARPA>
To: rpg@SU-AI.ARPA
Subject: Common Lisp groups
Dick,
I'm interested in the Object Programming and the Error Handling groups. I
believe I may have something to contribute to at least the former, and would
probably have something to do with implementing (for Spice Lisp) whatever comes
up in either case.
-- Steve
∂24-Sep-84 0953 RPG Mailing lists
∂23-Sep-84 2150 HANDERSON@CMU-CS-C.ARPA Mailing lists
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 21:50:06 PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Mon 24 Sep 84 00:49:16-EDT
Date: Mon, 24 Sep 1984 00:49 EDT
Message-ID: <HANDERSON.12050025895.BABYL@CMU-CS-C.ARPA>
From: Steven Handerson <Handerson@CMU-CS-C.ARPA>
To: rpg@SU-AI.ARPA
Subject: Mailing lists
Dick,
You could also put me in for the Graphics group, although I'll probably only
watch.
-- Steve
∂24-Sep-84 0957 RPG Add to Common Lisp SIGs
∂24-Sep-84 0106 FISCHER@RUTGERS.ARPA Add to Common Lisp SIGs
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 01:06:25 PDT
Date: 24 Sep 84 04:06:55 EDT
From: Ron <FISCHER@RUTGERS.ARPA>
Subject: Add to Common Lisp SIGs
To: rpg@SU-AI.ARPA
Please add me to the object oriented programming and windows
discussions. I am involved in two projects here that are working in
those areas and would like to contribute if possible.
Thanks, and good luck to you all,
(ron)
-------
Done.
∂24-Sep-84 1000 RPG Re: Working Groups
∂24-Sep-84 0919 larus%ucbdali@Berkeley Re: Working Groups
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 09:19:21 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.31)
id AA18996; Mon, 24 Sep 84 09:20:57 pdt
Received: by ucbdali.ARPA (4.24/4.38)
id AA11878; Mon, 24 Sep 84 09:19:08 pdt
From: larus%ucbdali@Berkeley (James Larus)
Message-Id: <8409241619.AA11878@ucbdali.ARPA>
Date: 24 Sep 1984 0919-PDT (Monday)
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc:
Subject: Re: Working Groups
In-Reply-To: Your msg of 23 Sep 84 1647 PDT
I believe that I signed up for the Error Handling subgroup at the Monteray
meeting, but I have not yet received any material on it.
Also, I would like to stay on both Common Lisp mailing lists after the split,
as I will be working on the SPUR Common Lisp impelementation.
Thanks,
/Jim
Done.
∂24-Sep-84 1007 RPG Online documents
To: quinquevirate@SU-AI.ARPA
Since December 1981 I've been keeping archives of all of the Common Lisp
mail here at Stanford. The files are ascii and are unprotected (FTPable
with no login). We currently have over 45000 free disk blocks and an
average load average of 1.5 during the middle of the afternoon. Soon we
will have a 4 gigabyte file system.
I mentioned this to Squires in Monterey, and he said that DARPA would make
sure SAIL had enough disk to handle the archives. With the working group
setups, I have all of those archives going here already.
I suggest that the archives stay at SAIL.
-rpg-
∂24-Sep-84 1013 STEELE@TL-20A.ARPA Online documents
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:13:14 PDT
Received: ID <STEELE@TL-20A.ARPA>; Mon 24 Sep 84 13:13:18-EDT
Date: Mon 24 Sep 84 13:13:16-EDT
From: STEELE@TL-20A.ARPA
Subject: Online documents
To: quinquevirate@SU-AI.ARPA
The only difference between the SAIL archives and mine is that mine
contains a number of messages that were not transmitted via the
COMMON-LISP mailing list for one reason or another. The SAIL copies
are almost certainly adequate for the future purposes of the
Common LISP committee. My version was important for making sure
nothing was lost in making revisions to the book. I will probably
continue to maintain my copy in parallel.
--Guy
-------
∂24-Sep-84 1032 RPG Re: Committees
∂21-Sep-84 1659 JonL.pa@Xerox.ARPA Re: Committees
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 21 Sep 84 16:58:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 21 SEP 84 16:59:19 PDT
Date: 21 Sep 84 16:58 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Committees
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 21 Sep 84 11:09
PDT
To: RPG@SU-AI.ARPA
cc: jonl.PA@XEROX.ARPA
It would probably make sense for me to associate with the "subsets"
committee -- considering my position as a Xerox employee. Beau hasn't
yet debriefed us about his views as to what happened in Monterrey -- am
still hoping that the notion of a mechanically translatable subset of
Interlisp will be acceptable to him.
Of course, I "like" Obj Oriented programming, but suspect that it may be
loaded with flavorLovers. Could bring a Loops perspective, but not
really that much experience to it.
Finally, I could offer some support for the iteration committee -- have
long been pushing for LOOP (not LOOPS!) to get in -- and the Interlisp
I.S.OPRS could be a fresh look too, although I think LOOP is very
similar.
Well, whatever you think. Who was in charge of parcelling out people to
commititees?
-- JonL --
Done. I am in charge of the working groups.
∂24-Sep-84 1033 RPG report of meeting about Common Lisp
∂22-Sep-84 0210 HEDRICK@RUTGERS.ARPA report of meeting about Common Lisp
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 22 Sep 84 02:10:30 PDT
Date: 22 Sep 84 05:11:10 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: report of meeting about Common Lisp
To: post-bboard@RUTGERS.ARPA
cc: titcomb@DEC-MARLBORO.ARPA, bein@SRI-PRISM.ARPA, rpg@SU-AI.ARPA
This is a report on the Common Lisp Workshop, held at the Naval
Postgraduate School, in Monterrey, CA, 18 and 19 Sept 84. The meeting
was called by ARPA, to examine the present state of CL, and to make
suggestions on where it should go next. The attendees were mostly
associated with organizations that were implementing CL or thinking of
doing so, though there were also some user organizations. There was a
mix of Universities, commercial vendors, etc.
The main thrust of the meeting seemed to be how CL would make the
transition between a nice idea dreamed up by a few language designers to
a language that is being supported by a large number of vendors and
required by ARPA. My discussion will follow the overall organization of
the sessions. (However this order is not chronological. It is
organized so that some of my users won't have to wade through technical
details to see what is likely to be of the most interest to them.)
ARPA policy
Subsets
Organizational issues
Proposed extensions
Workstation/server architecture
Multi-processing facilities
I. ARPA Policy
The folks who were here from ARPA were Ron Ohlander and Steve Squires.
Apparently Ron will be leaving ARPA (when? I didn't get the time - I
think within a year), and Squires will end up carrying the ball for CL.
Ron did most of the talking in this meeting.
One of the factors that is going to change the nature of CL is the fact
the ARPA is planning to push it strongly. No final decisions are made,
but it looks like ARPA is going to require and/or strongly suggest that
CL be used for its research contracts. This will be particularly the
case for the Strategic Computing project, since they intend for all
contractors involved in that project to be able to share code. They
made all the normal qualifications about doing this in a way that will
not stiffle innovation, and allowing exceptions as appropriate. But the
evidence is that they will exert very strong pressure towards CL. (They
mentioned in passing that they also plan to specify that systems they
pay for should use TCP/IP for networking. Incidentally, they also said
that if you want the RFP for the Strategic Computing initiative in new
architectures, you should ask for
N0039-84-R-0605(Q)
from the Naval Electronics Systems Command, Code 2013. The following
phone number is not for Code 2013, but they can refer you:
202-692-6085.)
One of the amusing results of ARPA's policies is that there is now a bit
of a battle over how much of CL you have to implement in order to
qualify. Certain vendors seem to be interested in providing some degree
of CL compatibility within their existing Lisps, and on that basis want
to be qualified to participate in cases where CL is specified. It is
not clear to what extent they have sound technical reasons for not
wanting to do full CL, and to what extent they feel that they don't have
time to do so soon enough.
ARPA seems to be willing to put at some money into helping CL get off
the ground, and also to supplying some clerical support, and possibly
legal and organizational advice.
II. Subsets
One of the questions which was posed is whether the CL community should
specify one or more official subsets. There are a number of reasons
why subsets might be desirable:
- several people have proposed a subset for teaching purposes. The
language is so big that many courses would probably prefer not
to deal with the whole thing. It might be helpful if different
texts would use the same subset. This could promote a
competitive marketplace. It might also be nice if our AI
textbooks and our Lisp programming intro assumed the same
subset! This might not mean a special implementation, since it
would be easy enough to hide the names of the functions that are
not in the subset. Instructional applications also tend to be
on small machines, and so might also fall afoul of the second
requirement:
- it might be nice to implement CL on small machines. Existing CL
implementations seem to take between 1 and 2.5 Mbytes of ram
(more if you count editors, etc.). It would be nice to be able
to have CL for the Macintosh and other smaller machines.
- full CL has features that may make it hard to do efficient
implementations. This could be important for slower micros. But
it also affects people interested in doing "embedded systems",
i.e. things that have to go inside missles, or that have to do
process control, etc. Examples of such features are lexical
binding, multiple values, and sequence functions. There was
considerable disagreement over how significant this issue is.
Some felt that with enough work all of these problems could be
overcome, but it does seem clear that the first implementations
of full CL are going to be noticably slower than simpler Lisps
such as PSL.
- some vendors may not find it practical to implement full CL
immediately. They would like to be able to start with a subset,
and have that be enough to qualify them to participate in
projects for which ARPA wants CL to be used.
There was no concensus on this issue. Discussion of subsets got off to
a slow start, but it kept coming up, and tempers starting getting hotter
as time went on. Here is my reading of the general reactions:
- people seemed to agree that an educational subset might be useful
and was harmless. No one seemed to feel that the CL designers
or this meeting were ready to specify such a subset. So it
seems that textbook writers will be left on their own, at least
until we see how a few of these subsets turn out.
- little was said about the small-machine problem.
- there was a lot of discussion about the last two types of subsets.
(They are hard to separate.) There were strong feelings on both
sides. Some people feel that only a full CL should be called
CL, and that we should not encourage subsets. Even the most
extreme holders of this view did feel sympathetic to purveyors
of existing Lisp implementations, and did agree that they should
be encouraged to provide whatever degree of CL compatibility
they felt they could manage. This issue is obviously going to
come up again at the next meeting, and will be discussed hotly
with ARPA in the meantime. ARPA will have a strong effect on
this. If they plan to require use of CL, then they will have
the final say on what they mean by CL. There will surely be
subsets of this kind. I would be willing to bet that ARPA will
allow it for embedded systems and process control, where there
are clear technical reasons. I have no idea what they will do
in other cases. (Maybe the Ada approach, where subsets are
allowed as long as there is a clear plan to move to a full
implementation.) There is also some indication that ARPA may
find it acceptable to do work in another Lisp as long as there
is a program to translate the results into CL. Clearly a subset
would qualify here.
Note that some of these "subsets" may not be real subsets. It is likely
that they will have to add a few features. E.g. those implementors who
do not want to bear the overhead of generic sequence functions may add a
few type-specific functions, such as STRING-CONCAT. It is quite likely
that people who do this will want these functions added to the full
language, so that their implementations will be true subsets.
III. Organizational issues
It is interesting to see how much difference it makes that this language
is going to be supported by vendors. They want to make sure
- that the language is well-defined. This means that there is some
authoritative way to answer questions, and that a validation
procedure is developed (including a validation suite).
- that it is possible to make changes where implementation experience
shows that it is desirable, or as the CL community comes up with
important new ideas
- that changes to the language do not happen too quickly
- that their interests are represented in whatever group is authorized
to change the language.
It is clear that these requirements imply a person or persons who
control the development of the language. Initially the language was
designed primarily by a group of 5 people (the so-called "gang of 5"),
with participation by many others over the Arpanet. The vendors that I
heard would like for those original designers to continue to have a
strong influence over the language. (Indeed the Gang of 5 is probably
the most enthusiastic to turn things over a formal organization.) Most
people see that we are going to start some organization analogous to a
standards committee. However most people do not want to be involved in
ANSI, ISO, etc. The feeling seems to be that there is too much
bureacracy, and that CL still needs enough clarification and additions
that we could not tolerate the delays involved in conventional standards
organizations. Clearly some vendors would like to see an ANSI standard
eventually, but everyone seems to agree that we are not ready yet. Here
is a partial list of things that the people responsible for the language
have to handle:
- some way to process proposals for changes to the language. Everyone
envisions that some sort of vote of a large CL community will be
required to approve changes. (This has been true all along,
except for last-minute details.) So we are looking for a person
or persons to receive suggestions, distribute them for comment,
and conduct votes if appropriate. I suspect that this group
might also solict suggestions and possible make some themselves.
- some way to give authoritative answers to questions that call for an
interpretation of the language specification
- destribution of any decisions that result from these two processes
to all interested parties
- an archive of all decisions, and possible of all discussion
- a "delta document". This would represent all changes that will show
up in the next edition of the CL manual. I.e. it is with
respect to the most recently published edition of the CL manual.
- new editions of the CL manual. Initially this may happen as often
as once a year
- maintenance of online documentation. This would be used by builtin
help facilities, etc. This will require some negotiation with
Digital Press, as they currently hold a copyright for the
manual.
- licensing special editions of the manual. Vendors may want to
intersperse details of their implementation in the text, so that
the user has a single, integrated manual for Vendor X's CL.
Most people seem to feel that this is OK as long as the manual
contains the unadulterated text of the official CL manual, with
all additions being set off visibly (e.g. printed in a
contrasting color). They may also allow subsets to cut parts of
the CL manual, but this will require that there is a clear
disclaimer that this is not CL. Anyway, somebody is going to
have to set reprint policies and monitor what is going on. This
will also have to be done in conjunction with Digital Press.
- a test/validation suite.
- implementation notes
- a library of public-domain CL code (the "yellow pages" library)
- a group to vote on changes and matters of policy. Generally some
way of providing "legitimacy" to the whole process.
- trademarking of the language. We are not sure whether it is too
late to trademark CL. One proposal is to trademark CL-84,
CL-85, etc. The date would be associated with a test suite (and
probably also an edition of the manual - these would be issued
at the same time). There is no clear concensus that
trademarking is needed, but it should at least be looked into.
- budget for clerical support, mailings, and other expenses associated
with the above.
We have an interim arrangement to handle all of this for the next 6
months. A committee will make a proposal for a permanent organization
to take effect at the end of 6 months. Probably there will be another
CL workshop at that time. The CL mailing list will continue to be used
to take votes on major issues, and generally to represent the CL
community as a whole. This list may be split, as there seem to be some
people who are just random users, and do not want to (or should not)
participate in the design decisions. The gang of 5 will moderate the
mailing list, and will also continue to take somewhat of a leadership
role in technical matters, i.e. answering questions, coordinating
proposed changes, etc. This coordination includes maintaining archives,
the delta document, etc. They will investigate some of the other
issues, such as licensing the manual for online use and special
editions, trademarks, and preparation of an initial budget. (This budget
will probably be covered by ARPA.) They will try to do something about
the Yellow Pages library. (There is actually already one at CMU. Maybe
this will just continue for the interim period.) Committees were
appointed to propose extensions to the language in several important
areas (see below). The results will be discussed on the CL mailing
list. There is also a committee to propose a permanent organization.
It is likely that some funding will be needed for the 6 month interim,
if only to handle clerical support. There way a broad hint that the
Gang of 5 might find ARPA receptive to a proposal that ARPA fund this.
IV. Proposed extensions
No one was crazy enough to propose that we should come up with
extensions to CL on the spot during the meeting. Instead we tried to
agree on what areas are the most important to look into. Committees
volunteered to look into each of these areas. We hope that they will
propose extensions. I think most of us agree that the actual language
design is going to be done by individuals or very small groups in each
case. The committees are thus the people who want to be in on initial
discussions, and also people who are considering writing proposals or
parts of proposals. Here was the initial set of extensions proposed:
object-oriented programming
window support
error handling
multiprocessing support
graphics
iteration (e.g. some sort of macros for writing loops)
facilities to monitor the internal state of Lisp
interface to the surrounding system
networking
interface to database facilities
configuration and version management tools
pattern matching
calling foreign (non-Lisp) functions
destructuring
international character sets
program manipulation facilities
coercion among numerical types
storage management
We took a vote, giving each person 6 votes. Most of the above
received 0 to 4 votes. The only significant votes were for the
following items.
almost 100% - object-oriented programming
almost 100% - error handling
about 50% - display support (windows, etc.)
about 50% - calling foreign (non-Lisp) functions
about 33% - iteration
about 33% - graphics
These are the areas for which committees were set up.
V. Workstation/server architecture
A number of people expect that we will continue to have systems of
differing power. That is, in your office will be something for around
$15K. It will be able to handle CL. You will do a lot of your
development work on it. But when you want to process a lot of
real-world data, you will want a more powerful machine. These machines
would likely be $100K or more. The folks from ARPA seemed to feel that
configurations like this would be important for their Strategic
Computing projects.
The issue put before us was what sort of language facilities are needed
to support this. No one seemed to feel that we knew enough of this sort
of thing that we were ready to add such facilities to the language. Of
course individual researchers would make extensions in the course of
their research. But we would like to see several such projects before
adopting a particular design permanently.
VI. Multi-processing facilities
This discussion was somewhat similar to the previous one. We envision
multiprocessing as becoming more important as time goes on. Again, the
Strategic Computing project is likely to use this. The question is what
language facilities will be needed to support multiprocessing. No one
feels we know enough about this area to say at the moment. Brief
mention was made of several pieces of work in this area:
Gabriel's work at Stanford
Halstead's at MIT
Both of these are shared-memory.
the remote sensing project at CMU. Multiple PERQ's with CL.
Uses the facilities of the PERQ OS.
This is more like conventional networking.
BBN's butterfly project. Many 68000 systems in parallel, with a Lisp
Machine as a front end to supply the user interface. Both
the 68000's and the LM will use CL.
It is clear that there are not only many different approaches, but even
more than one basic model (shared memory and networking are sort of the
opposite ends of the spectrum). In the end we may need language
facilities to support both styles. But nobody is ready to say much at
the moment.
Anyone interested in working on multiprocessing support is invited to
send mail to RPG@SU-AI to be added to a mailing list.
-------
∂24-Sep-84 1033 FAHLMAN@CMU-CS-C.ARPA Online documents
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:32:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Sep 84 13:31:51-EDT
Date: Mon, 24 Sep 1984 13:31 EDT
Message-ID: <FAHLMAN.12050164721.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA
Subject: Online documents
In-reply-to: Msg of 24 Sep 1984 13:07-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Great, sounds like keeping the moby mail file at SU-AI is the right
move, since it's there already, and since they've already approached
DARPA about making sure that there's always enough disk. It sounds like
they have many more available cycles than CMUC has as well. Also, this
will make life easier if RPG ends up (one way or another) as the person
to see if you need hardcopy or tape.
Given the way people will be using this stuff, it is important to break
the mail file up into manageable chunks. I suggest that RPG do this and
then post a pointer to these files on on the Common Lisp mailing list.
Is it possible to run some sort of file-reading/searching program over
the net? I'm thinking of the case where I want to find the messages on,
say, function specs, and don't want to pull the whole mess over to my
machine in order to do this. If such access cannot be granted to the
whole net, maybe some sort of guest account could be set up just for the
use of the executive committee.
One-stop shopping is always a good idea. I guess we should put the
master distribution copies of the other documents in the same place,
though copies may also exist elsewhere. The five of us will need to be
able to write files into this public directory, unless RPG wants to
handle all such transfers himself (not a bad idea if he has time).
-- Scott
∂24-Sep-84 1053 FAHLMAN@CMU-CS-C.ARPA Subgroups
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:52:41 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Sep 84 13:51:31-EDT
Date: Mon, 24 Sep 1984 13:51 EDT
Message-ID: <FAHLMAN.12050168285.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA
Subject: Subgroups
It occurs to me that I am only going to be a really active member of a
couple of the subcommittees, but that I am quite interested in keeping
an eye on all (or almost all) of them. Partly, this is just nosiness
(which I think is appropriate for a member of the executive committee),
but it is also the case that I might have useful information to
contribute if certain questions come up in any of these groups. Of
course, if there's really a flood of activity, I might have to back down
from this position, but I'd like to try listening in on all the
discussions for awhile.
I am wondering if the rest of you feel the same way. If so, maybe we
should just say that the executive committee members are automatically
placed on the mailing list for all of these groups, though we would not
be group members in the sense of being expected to contribute proposals
and the like. If the rest of you don't share my desire to monitor these
proceedings, maybe I should just join all the groups myself, as an
individual. Opinions?
-- Scott
∂24-Sep-84 1057 RPG Mailing list administrivia
∂23-Sep-84 1334 KMP@MIT-MC Mailing list administrivia
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Sep 84 13:34:01 PDT
Date: 23 September 1984 16:30-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Mailing list administrivia
To: RPG @ SU-AI
cc: COMMON-LISP-REQUEST @ MIT-MC
Reply-To: COMMON-LISP-REQUEST@MC
I created the following mailing lists on MC:
Full Name Alias Purpose
COMMON-LISP-FORUM CL-FORUM ==> COMMON-LISP-FORUM@SAIL
COMMON-LISP-FORUM-LOCAL none Local distribution.
COMMON-LISP-IMPLEM CL-IMPLEM ==> COMMON-LISP-IMPLEM@SAIL
COMMON-LISP-IMPLEM-LOCAL none Local distribution.
COMMON-LISP-REQUEST CL-REQUEST Local list maintenance.
When you get around to revamping COMMON-LISP@SAIL, please add
COMMON-LISP-FORUM-LOCAL@MC and COMMON-LISP-IMPLEM-LOCAL@MC as
recipients to the revamped lists and send me a list of the people
who should be on those lists (so you can remove them from your
distribution list).
When we really open up these lists to a larger audience, local
redistribution such as this will hopefully keep the mailers involved
from becoming swamped. If for some reason you don't agree and would
rather retain control of either or both of these lists on SAIL,
just let me know and I'll undo these changes. I haven't announced
them anywhere. Also, obviously, the choice of names is still flexible.
-kmp
Your mailing list setup is ok. But change it as follows:
COMMON-LISP-IMPLEM CL-IMPLEM ==> COMMON-LISP-IMPLEMENTATION@SAIL
∂24-Sep-84 1058 RPG Contracts with Digital Press
∂24-Sep-84 1010 STEELE@TL-20A.ARPA Contracts with Digital Press
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:10:17 PDT
Received: ID <STEELE@TL-20A.ARPA>; Mon 24 Sep 84 13:09:46-EDT
Date: Mon 24 Sep 84 13:09:44-EDT
From: STEELE@TL-20A.ARPA
Subject: Contracts with Digital Press
To: rpg@SU-AI.ARPA
cc: fahlman@CMU-CS-C.ARPA, ohlander@USC-ISI.ARPA
I have received a copy of DG's proposed contract with Digital Press.
It looks fairly reasonable to me, although in its present form it does
not provide for editorial review before publication. It also provides
no specification of the title to be used and no constraint on how the
text might be modified.
I have also received a letter from John Osborn of Digital Press.
I will send a photocopy to you (Dick). In brief, he makes three points:
(1) He thinks Digital Press should cooperate fully with other vendors
in rendering verbatim copies of the book in whatever format they desire.
Other vendors may manufacture the books to their own specifications.
[I assume he means physical specifications, such as covers. He does
not explicitly address the issue of on-line copies.]
(2) He thinks DP should not license derivative works, but promote the idea
of separate supplementary pages.
(3) All requests for changes to the book will be redirected to the
Common LISP committee.
So points (1) and (3) are certainly what we want, and I suspect that
(2) is negotiable.
--Guy
-------
∂24-Sep-84 1116 RPG LISP mailing list
∂24-Sep-84 1046 dzg@cmu-cs-spice.arpa LISP mailing list
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:46:42 PDT
Date: 24 Sep 1984 13:38:14-EDT
From: Dario.Giuse@CMU-CS-SPICE
To: rpg@suai
Subject: LISP mailing list
Hi. I have been using Common Lisp quite a bit here at CMU, and I'd like
to be added to the Common LISP mailing list. Scott tells me you are the
one to contact.
Also, Scott mentioned there are several committees that work on different
areas. I am especially interested in graphics and support for window
managers. Could you give more details on how the committes work and so on?
Thanks a whole lot.
- Dario -
The committees are simply a discussion group in which proposals for standards
or hooks into the guts of CL are passed around. Concrete proposals emerge
from the committee to be reviewed by the CL community.
-rpg-
∂24-Sep-84 1117 RPG One more little change
∂24-Sep-84 1035 KMP@MIT-MC One more little change
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:35:07 PDT
Date: 24 September 1984 13:34-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: One more little change
To: RPG @ SU-AI
cc: COMMON-LISP-REQUEST @ MIT-MC
Reply-To: COMMON-LISP-REQUEST@MC
Date: 23 Sep 84 1603 PDT
From: Dick Gabriel <RPG at SU-AI.ARPA>
Your mailing list setup is ok. But change it as follows:
COMMON-LISP-IMPLEM CL-IMPLEM ==> COMMON-LISP-IMPLEMENTATION@SAIL
Well, in the interest of standardizing on names, I made it be the following instead:
COMMON-LISP-IMPLEMENTATION CL-I, CL-IMPLEM ==> COMMON-LISP-IMPLEMENTATION@SAIL
That way, people who omit the "@SAIL" locally will still tend to win.
I also changed the local distribution name to COMMON-LISP-IMPLEMENTATION-LOCAL
(from COMMON-LISP-IMPLEM-LOCAL) for consistency. For that to work, you'll need to change
it on your end, too.
-kmp
∂24-Sep-84 1124 RPG Online...
To: quinquevirate@SU-AI.ARPA
The file is already broken up into chunks. People can browse the files
without logging in. I would prefer that people log in to modify themm however.
I can arrange for all of us to have accounts on SAIL. I think Moon and Steele
already have accounts. Let me look into the various searching programs we have.
I use our editor, but it is tailored to our display system.
I am willing to manage the files, including transfers, for a while. If this bogs
down, I can get one of my employees (!) to help out.
∂24-Sep-84 1134 RPG
∂24-Sep-84 1120 FAHLMAN@CMU-CS-C.ARPA
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 11:20:30 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Sep 84 14:19:06-EDT
Date: Mon, 24 Sep 1984 14:18 EDT
Message-ID: <FAHLMAN.12050173295.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
In-reply-to: Msg of 24 Sep 1984 14:11-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
OK, thanks. With the two of us watching, maybe we can head off any
proposals that go against the grain of the rest of the language, or at
least raise a red flag when we spot trouble.
-- Scott
∂24-Sep-84 1136 RPG Online documents
∂24-Sep-84 1033 FAHLMAN@CMU-CS-C.ARPA Online documents
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 10:32:45 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 24 Sep 84 13:31:51-EDT
Date: Mon, 24 Sep 1984 13:31 EDT
Message-ID: <FAHLMAN.12050164721.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: quinquevirate@SU-AI.ARPA
Subject: Online documents
In-reply-to: Msg of 24 Sep 1984 13:07-EDT from Dick Gabriel <RPG at SU-AI.ARPA>
Great, sounds like keeping the moby mail file at SU-AI is the right
move, since it's there already, and since they've already approached
DARPA about making sure that there's always enough disk. It sounds like
they have many more available cycles than CMUC has as well. Also, this
will make life easier if RPG ends up (one way or another) as the person
to see if you need hardcopy or tape.
Given the way people will be using this stuff, it is important to break
the mail file up into manageable chunks. I suggest that RPG do this and
then post a pointer to these files on on the Common Lisp mailing list.
Is it possible to run some sort of file-reading/searching program over
the net? I'm thinking of the case where I want to find the messages on,
say, function specs, and don't want to pull the whole mess over to my
machine in order to do this. If such access cannot be granted to the
whole net, maybe some sort of guest account could be set up just for the
use of the executive committee.
One-stop shopping is always a good idea. I guess we should put the
master distribution copies of the other documents in the same place,
though copies may also exist elsewhere. The five of us will need to be
able to write files into this public directory, unless RPG wants to
handle all such transfers himself (not a bad idea if he has time).
-- Scott
Online...
The file is already broken up into chunks. People can browse the files
without logging in. I would prefer that people log in to modify themm however.
I can arrange for all of us to have accounts on SAIL. I think Moon and Steele
already have accounts. Let me look into the various searching programs we have.
I use our editor, but it is tailored to our display system.
I am willing to manage the files, including transfers, for a while. If this bogs
down, I can get one of my employees (!) to help out.
∂24-Sep-84 1137 RPG Re: CL History
∂14-Sep-84 1636 JonL.pa@Xerox.ARPA Re: CL History
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 14 Sep 84 16:35:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 84 16:31:56 PDT
Date: 14 Sep 84 16:31 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: CL History
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 14 Sep 84 08:48
PDT
To: RPG@SU-AI.ARPA
cc: steele@TL-20A.ARPA, jonl.PA@XEROX.ARPA
Below is a copy of a historical note which I sent to the group in August
1982, because the material was still fresh on my mind (and because it
was clear that Xerox was not then going to have a significant
involvement with Common Lisp, so that "history" would probably be my
last major contribution for some time to come).
Incidentally, the technal staff -- Larry, Bill, and myself -- have been
asked by Xerox management *not* to attend the meeting next week. Beau
Sheil and Gary Moskovitz (the new head of the A.I. Systems Business
Unit) will represent Xerox. Sigh.
------------------------------------------------------------------
Mail-from: Arpanet host MIT-MC rcvd at 24-AUG-82 1950-PDT
Date: 24 August 1982 22:44-EDT
From: Jon L White <JONL at MIT-MC>
Subject: Roots of "Yu-Shiang Lisp"
To: JONL at MIT-MC, RPG at SU-AI, Guy.Steele at CMU-10A,
Fahlman at CMU-10A
cc: MOON at MIT-MC, Shostak at SRI-CSL, Griss at UTAH-20, DLW at MIT-AI,
RG at MIT-AI, GSB at MIT-ML, Brooks at CMU-20C,
Scherliss at CMU-20C, Engelmore at USC-ISI, Balzer at USC-ISIB,
Hedrick at RUTGERS
In a brief attempt to remember the roots of "Yu-Shiang Lisp", subsequently
named COMMON LISP, I searched my old mail files which are still on-line,
and found a few tidbits of history. Mostly, my mail stuff got deleted,
but the "Call" for the conference at SRI on Apr 8, 1981, by Bob Engelmore
survived, along with an interchange, about a week after the "birth",
between Ed Feigenbaum and Scott Fahlman. These I've packeged up in the
file at MIT-MC JONL;COMMON HIST along with Chuck Hedrick's overall summary
of the April 8 meeting.
I'd like to ask you all to jog your memory cells, and see if any of the
uncertainties below can be filled in, and if additional significant
steps towards the CommonLisp can be identified. Needless to say, this
listing is a view from where I was standing during those days.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Mar 12, 1981: Bob Engelmore invites many Lisp implementors and users
from the ARPA community to a conference at SRI to clear up issues
surrounding the future of Lisp. Since ARPA was diminishing its
support of Lisp development and maintenance, his "call" may have
had the seeds of CommonLisp in it's second paragraph:
" . . . There are now several respectable Lisp dialects in
use, and others under development. The efficiency,
transportability and programming environment varies significantly
from one to the other. Although this pluralism will probably
continue indefinitely, perhaps we can identify a single
"community
standard" that can be maintained, documented and distributed in a
professional way, as was done with Interlisp for many years. "
Apr 8, 1981: Moby meeting at SRI. InterLisp crowd appears to be unified;
Scott Fahlman characterises the post-MacLisp crowd as 4 horses going in 5
directions. Nils Nilsson, over a glass of beer, asks Jonl to join SRI in
beginning a Lisp development and maintenance center; Jonl insists on RPG
being a principal of the effort. The advantages of a Lisp with Arpa
support, which "... can be maintained, documented and distributed in a
professional way ...", appeared enormous.
Apr 9, 1981: RPG, Jonl, and GLS ride in a cramped car to Livermore,
during which time the prospect of merging the Vax/NIL, S-1/NIL, and
Spice/Lisp projects is proposed to GLS. Some technical obstacles are
worked out. Later that night, at Brian Reed's house, SEF is apprised of
the prospects. He too quickly realizes the advantages of a common dialect
when presenting plans to funding agencies; more technical details are
worked out, in particular the administrative plan of the CMU folks that
the manual will be written first before coding commences, and the manual
will be under the control of GLS.
Apr 10, 1981: Jonl and RPG meet with Nils Nilsson, Gary Hendrix, Karl
Leavitt, Jack Goldberg, and Rob Shostack; brief outline is made of what
SRI would contribute, what Lawrence-Livermore would contribute, and what
CMU would contribute. Nils takes plans to Arpa to "get a reading".
Apr 13, 1981: More meetings between RPG, Jonl, and Goldberg, Leavitt,
Shostack. SRI has a proposal for a "portable InterLisp" in the works, and
the NIL/Spice plan is to be merged with that project, under the CSL
section. Details are worked out about how CMU will retain "ownership" of
the manual, but SRI will be a distribution center.
Later that week: Nils reports mixed reception in Washington from Arpa.
SEF and GLS are already back at CMU. Plans are made to meet at CMU
sometime "soon" since the S-1/NIL group will be re-locating to CMU for the
summer.
Next week: Feigenbaum gives tacit approval to the plan, in an Arpa-Net
letter to SEF. Such support is received with joy.
May 1981: Jonl and Shostak prepare a written plan for SRI involvement,
with a view to obtaining ARPA funding.
First week of June (Saturday): Meeting at CMU to resolve particular
language
issues. Attending were GLS, SEF, RPG, JONL, Bill Scherliss, and Rod
Brooks. A lot of time was spent on treatement of Multiple-values;
NIL versus () remains unresolved. Lunch is had at Ali Baba's, and
the name Yu-Shiang Lisp is proposed to replace Spice Lisp; also
proposed
is to retain the generic name NIL, but to specialize between
Spice/NIL
S-1/NIL, Vax/NIL etc. Importance is recognized of bringing in the
other post-MacLisp groups, notably Symbolics and LMI.
July: Report from ARPA looks negative for any funding for proposal from
SRI.
Summer: Symbolics greets the idea of a "standardizing" with much
support. Noftsker in particular deems it desirable to have a
common dialect on the Vax through which potential LispMachine
customers can be exposed to Lisp. Moon pushes for a name, which
by default seems to be heading for CommonLisp. GLS produces the
"Swiss Cheese" edition of the Spice Lisp manual.
Sept: Change in administration in ARPA casts new light on SRI hopes:
A big "smile" is offered to the plan, it is met with approval, but
but not with money. Later on, it appears that hopes for an ARPA
proposal are futile; word is around even that ARPA is pulling out
of the InterLisp/VAX support.
Last week of November 1981: Meeting in Cambridge, at Symbolics, to resolve
many issues; excelent "footwork" done by GLS to get a written notebook to
each attendee of the various issues, along with a Ballot sheet. First day
goes moderately; second day degenerates into much flaming. Many hard
issues postponed. Several other groups were now "aboard", in particular
the InterLisp community sent Bill vanMelle as a observer.
[At some point in time, RPG contacted the Utah people to get them to
interested. Also, RPG dealt with Masinter as a representative of the
InterLisp Community? Bill Woods at BBN also expresses interest in
the development, so that InterLisp can keep "up to date".]
Fall 1981: Michael Smith, major sales representative of DEC, asks for
advice on getting DEC into the lisp market. Both outside customers
and internal projects make it imperative that DEC do something soon.
Internally, Chinnaswamy in Engineering at the Marlborough plant, and
John Ulrich in the new "Knowledge Engineering" project at Tewksbury
apply internal pressure for DEC to take action quickly.
Mid December, 1981: Sam Fuller calls several people in to DEC for
consultation about what DEC can do to support Lisp. Jonl makes a case for
DEC joining the CommonLisp bandwagon, rather than any of the other options
namely: jump in wholeheartedly behind InterLisp/VAX, or behind Vax/NIL,
or (most likely) strike aout afresh with their own DEC Lisp. Chuch
Hedrick is given a contract by DEC's LCG (the TOPS-20 people) to do an
extended- addressing 20-Lisp, of whatever flavor is decided upon by the
VAX group.
Jan 1982: DEC gives CMU a short contract to develop a CommonLisp on the
VAX.
Spring 1982: Discussion continues via ARPA-net mails, culminating in a
very productive day long session at CMU on Aug 21, 1981.
∂24-Sep-84 1321 RPG
∂24-Sep-84 1305 lseward@rand-unix
Received: from RAND-UNIX.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 13:03:30 PDT
Received: by rand-unix.ARPA; Mon, 24 Sep 84 12:36:24 pdt
From: Larry Seward <lseward@rand-unix>
Message-Id: <8409241936.AA28401@rand-unix.ARPA>
Date: 24 Sep 84 12:36:20 PDT (Mon)
To: rpg@su-ai
Please move me to the common lisp discussion list.
thanks.
larry seward.
∂25-Sep-84 1017 RPG Graphics and Window subgroups
∂24-Sep-84 1349 JW-PETERSON@UTAH-20.ARPA Graphics and Window subgroups
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 13:48:59 PDT
Date: Mon 24 Sep 84 14:50:17-MDT
From: John W. Peterson <JW-Peterson@UTAH-20.ARPA>
Subject: Graphics and Window subgroups
To: rpg@SU-AI.ARPA
Hi.
Bob Kessler mentioned to me two new lisp discussion groups on
"extended"(??!?) common lisp, Graphics and Windows. I've been designing
window-based computer aided design system in Lisp (PSL) for the past
couple years and would be interested in tuning in.
Thanks,
jw-peterson@utah-20
-------
Done
∂25-Sep-84 1019 RPG Please add me to Common Lisp.
∂24-Sep-84 1534 jml@cmu-cs-spice.arpa Please add me to Common Lisp.
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 24 Sep 84 15:34:30 PDT
Date: Monday, 24 September 1984 18:29:55 EDT
From: Jim.Large@cmu-cs-spice.arpa
To: rpg@su-ai.arpa
Subject: Please add me to Common Lisp.
Message-ID: <1984.9.24.22.26.56.Jim.Large@cmu-cs-spice.arpa>
I'd like to be on the common lisp list. When you split it, I'd like
to be on the implementor's side.
-- Jim Large
Perq systems
Done
∂25-Sep-84 1242 FAHLMAN@CMU-CS-C.ARPA Kyoto Common Lisp
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 25 Sep 84 12:41:44 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 25 Sep 84 15:40:46-EDT
Date: Tue, 25 Sep 1984 15:40 EDT
Message-ID: <FAHLMAN.12050450335.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Kyoto Common Lisp
There has been some confusion, partly my fault, about whether the Kyoto
University version of Common Lisp is based on our portable Spice Lisp
code. I have just received a letter from Taiichi Yuasa of Kyoto
University which makes clear that their implemenation is TOTALLY
INDEPENDENT of our code. They did receive some early drafts of the
manual, papers, and benchmark code from us (by way of Nippon Data
General), but they did not receive any Lisp system code from us until
several months AFTER their implemenation was finished and running. I
just wanted to set the record straight. They apparently got this
implementation running from a standing start in five months with a team
of four people, with no direct input at all from the Common Lisp
designers -- an awesome performance.
To further clarify things, Data General has their own implemenation for
the Eclipse. This is the one that was demonstrated at AAAI, and it IS
based on our code, though the task of porting it to Data General
hardware was done with essentially no help from CMU.
-- Scott
∂25-Sep-84 2120 RPG Change in Teknowledge representation
∂25-Sep-84 1343 LARK@SUMEX-AIM.ARPA Change in Teknowledge representation
Received: from SUMEX-AIM.ARPA by SU-AI.ARPA with TCP; 25 Sep 84 13:43:49 PDT
Date: Tue 25 Sep 84 13:44:22-PDT
From: Jay S. Lark <LARK@SUMEX-AIM.ARPA>
Subject: Change in Teknowledge representation
To: cl-subsets-request@SU-AI.ARPA
cc: WHITE@SUMEX-AIM.ARPA
My name was meant as a place-holder for our organization. Our representative
now is Bill White (WHITE@SUMEX), so you can add his name and remove my name
from the mailing list. Thanks.
jay
-------
Done
∂25-Sep-84 2122 RPG
∂25-Sep-84 2047 CSTACY@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 25 Sep 84 20:47:14 PDT
Date: 25 September 1984 23:47-EDT
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: cl-object-oriented-programming-request @ SU-AI
I would like to be on the cl-object-oriented-programming list, so
that I can receive and keep up on the discussion (I am not writing
a CL implementation but have great interest in it.)
Done
∂26-Sep-84 0756 RPG Re: Working Groups
∂26-Sep-84 0051 DDYER@USC-ISIB.ARPA Re: Working Groups
Received: from USC-ISIB.ARPA by SU-AI.ARPA with TCP; 26 Sep 84 00:48:30 PDT
Date: 26 Sep 1984 00:46:46 PDT
Subject: Re: Working Groups
From: Dave Dyer <DDYER@USC-ISIB.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
In-Reply-To: (Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of 23 Sep 84 1647 PDT)
I'd like to at least audit the groups on windows, objects, and graphics.
-------
Done.
∂27-Sep-84 1052 RPG Please add me ty your group
∂27-Sep-84 0737 DUGGAN@UTAH-20.ARPA Please add me ty your group
Received: from UTAH-20.ARPA by SU-AI.ARPA with TCP; 27 Sep 84 07:37:16 PDT
Date: Thu 27 Sep 84 08:39:01-MDT
From: Jerry Duggan <duggan@UTAH-20.ARPA>
Subject: Please add me ty your group
To: cl-object-oriented-programming@SU-AI.ARPA, cl-subsets@SU-AI.ARPA
I work with Bob Kessler at the University of Utah.
Jerry Duggan
-------
Done
∂29-Sep-84 1426 @SU-SCORE.ARPA:FAHLMAN@CMU-CS-C.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 29 Sep 84 14:25:21 PDT
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Sat 29 Sep 84 14:21:56-PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 29 Sep 84 17:23:40-EDT
Date: Sat, 29 Sep 1984 17:23 EDT
Message-ID: <FAHLMAN.12051517644.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem@MIT-MC.ARPA
Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Subject: Questions about specification and possible implementations
I've been a bit busy, but since nobody else has popped up to answer your
questions, I'll take a crack at them. I'll try to distinguish between
cases where I think the standard is clear and cases where there is
ambiguity and I am offering my own opinion as to how the ambiguity
should be resolved.
... some functions with all the &OPTIONAL and &KEY arguments may be
difficult or inefficient to implement as true functions, and thus may
be implemented as FEXPRs in the interpretor and MACROs in the
compiler.
I don't see why you think that such a change would make things easier
or more efficient.
The question is, what will (FUNCTION foo) do if foo is the
name of a MACRO or FEXPR?
I think "it is an error" to call FUNCTION on a symbol with no
definition or whose definition is not a true function. Some
implementations may just return whatever is in the SYMBOL-FUNCTION cell
without checking, but such a value cannot be used in APPLY. It is not
possible, in general, to create a true function that does what the MACRO
or special form does.
The book says the set of special forms is fixed and no way is provided
to make new ones. But is any way provided to define some of the
special forms from LISP level in the first place, or must all be
handcoded in assembly language or C etc.? Is any way provided to
install bugfixes in special forms by overlaying the old definition
with a new one?
There is no way in Common Lisp to create new special forms. It would
have been quite easy to define such a mechanism, but we deliberately
left such a mechanism out in the belief that having only a small, fixed
set of special forms makes it much easier to write various kinds of
program-manipulation tools. It was also felt that macros are an
adequate substitute for new special forms.
If you are implementing a Common Lisp, you are free to think up any
internal mechanism you like for defining special forms at Lisp level.
In our Spice Lisp implemenation, we use a version of the old FEXPR
mechanism to define most of these things, but we do not make this
available at user level.
At the front of the chapter on numbers it claims:
(LET ((X Z) (Y Z))
(EQ X Y))
may be false if the value of Z is a number. I can't see a mechanism
for this in any reasonable LISP unless Z is not only presently a
number but has been declared a number and this is compiled code which
represents the value of Z as a machine number instead of a LISP
object, whereas X and Y are undeclared and thus LISP objects, so new
objects must be constructed for X and Y to hold the value Z, and these
new objects won't be EQ to each other. But could somebody who really
knows tell me what the true explanation is?? The book leaves this a
complete mystery.
I'm not able to parse that sentence (PDL overflow), but what we had in
mind was the case where Z is defined in a defconstant to be, say, a
number or a character. In this case, we want it to be legal to
substitute that constant value for Z. Now, if the object is immediate,
X and Y would be EQ, but if the object is consed you might end up with
X and Y pointing to distinct structures that are not EQ but that are EQL.
In the introductory chapter, the Common-LISP book says semicolon
causes all characters up to eol to be discarded, but doesn't say
whether eol is kept or discarded.
All of these are answered quite clearly in the I/O chapter -- the
discussion in the intro was not meant to be definitive. In this case,
the EOL is discarded.
Ditto, doesn't say which characters inside "" are automatically
letterified and which have their usual semantic effects and thus need
explicit letterification to be treated as string text.
Only double-quote and the single-escape character (normally backslash)
need to be backslashed in a string.
Ditto, backslash at end of line does what? (Illegal, quote just the
next character which may be half of a crlf on some systems, quote the
eol token always?)
Quotes the Newline character which is virtually there, regardless of the
system's usual conventions. This is poor and confusing practice in most
situations, however. Use #\newline.
Ditto, vertical-bar, same questions as for "".
Only the single and multiple escape characters, normally vbar and
backslash, need to be quoted.
When COPY-SYMBOL is done, the pnames will be the same, but will they
be EQ or just EQUAL?
This is not clear in the manual. In my opinion, this should be left up
to the implementor. The new pname may or may not be EQ to the old one.
The book doesn't say what (/ 1 0) does. Is it an error, or does it
signal an error, or does it return the ratio of 1/0 as a way of
representing infinity, or what?
Certainly it "is an error" in portable common Lisp. I would expect
every implementation to signal an overflow or divide-by-zero error
unless it has actually implemented some sort of non-standard extension
to handle infinities and infinitesimals.
If NIL is an element of an assoc list, does this element get skipped
over by ASSOC et al or is it a stop flag?
Didn't you even try looking in the manual? As it says on page 279, NIL
is allowed to be an element of an A-list and is simply passed over.
How are the axis numbers of an array numbered, that is if you
create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0)
return 3 or 7?
This is not stated, but seems obvious. The numbering is left-to-right, 0
to whatever. So in this case the answer is 3.
-- Scott
∂30-Sep-84 1327 RPG Archives
To: Common-lisp@SU-AI.ARPA
The archives of Common Lisp mail is located on the directory [COM,LSP]
at SAIL. SAIL is a nickname for SU-AI.
COMMON.MSG[COM,LSP] ;July 28, 1983 - present
COMMON.3[COM,LSP] ;May 17, 1983 - July 28, 1983
COMMON.2[COM,LSP] ;Oct 2, 1982 - May 17, 1983
COMMON.1[COM,LSP] ;Dec 30, 1981 - Oct 1, 1982
SUBGRP.CL[COM,LSP] ;index to Common Lisp subgroup mailing lists
CLOBOR.MSG[COM,LSP] ;Object Oriented subgroup archives
CLWIND.MSG[COM,LSP] ;Window subgroup archives
CLITER.MSG[COM,LSP] ;Iteration subgroup archives
CLGRAP.MSG[COM,LSP] ;Graphics subgroup archives
CLFOFU.MSG[COM,LSP] ;Foreign Function Call subgroup archives
CLSUBS.MSG[COM,LSP] ;Subsets subgroup archives
CLVALI.MSG[COM,LSP] ;Validation subgroup archives
CLCHRT.MSG[COM,LSP] ;Charter subgroup archives
CLERHA.MSG[COM,LSP] ;Error Handling subgroup archives
CLMULT.MSG[COM,LSP] ;Multiprocessing subgroup archives
You can FTP these files away without logging in. Also you can type page
ranges with the monitor command: TYPE COMMON.MSG[COM,LSP](23:34).
Page 1 of each file is a directory of the rest of the file.
To search or otherwise read these files, you can use our editor, called E.
Perhaps you can use the SAIL display service to do this. Say HELP DISPLAY
and HELP E to find out about these possibilities. Also, SAIL supports the
SUPDUP protocol, and you can use E much as we do at SAIL in this mode.
SAIL TELNET supports DataMedia display service. Say HELP TELNET to find out
about these possibilties.
-rpg-
∂01-Oct-84 0951 RPG Common Lisp List
∂01-Oct-84 0633 gruber%umass-cs.csnet@csnet-relay.arpa Common Lisp List
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 1 Oct 84 06:33:49 PDT
Received: from umass-cs by csnet-relay.csnet id ak27788; 1 Oct 84 9:17 EDT
Date: Fri, 28 Sep 84 12:57 EST
From: Thomas Gruber <gruber%umass-cs.csnet@csnet-relay.arpa>
To: rpg%su-ai.arpa@csnet-relay.arpa
Subject: Common Lisp List
I wear two hats with respect to Common Lisp, and would like to have each
head on a list. Right now I get get common-lisp mail via csnet at DEC.
I also have an interest in representing the University of Massachusetts.
So, could you put me on the new common-lisp lists as follows:
implementer's list: gruber%bartok.dec@decwrl.arpa
general common lisp: gruber.UMass-CS@csnet-relay
Thanks,
Tom Gruber
∂03-Oct-84 0736 heller%umass-cs.csnet@csnet-relay.arpa Questions about OPEN
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 07:36:12 PDT
Received: from umass-cs by csnet-relay.csnet id ax03131; 3 Oct 84 10:11 EDT
Date: Wed, 3 Oct 84 08:26 EST
From: Robert (LISPer 68K)Heller <heller%umass-cs.csnet@csnet-relay.arpa>
To: common-lisp%su-ai.arpa@csnet-relay.arpa
Subject: Questions about OPEN
I have some questions about what the function OPEN returns if
:DIRECTION is :PROBE:
1) if the file exists, does OPEN return a closed stream?
2) if the file does not exist and :IF-DOES-NOT-EXIST is
:CREATE, what does OPEN do? create an empty and return a
closed stream?
I realize that the second case is somewhat pathological, but
I want to implement something reasonable for OPEN. The manual
(published edition) is not very clear about just what OPEN does with
a :DIRECTION of :PROBE. It just says that OPEN does not really open
the file, just tests for its existence.
Robert Heller
Heller%UMass-CS@CSNet-Relay
∂03-Oct-84 1131 RPG Re: Introduction
∂03-Oct-84 0911 Bobrow.pa@Xerox.ARPA Re: Introduction
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 09:10:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 OCT 84 09:10:59 PDT
Date: 3 Oct 84 09:10 PDT
From: Bobrow.pa@XEROX.ARPA
Subject: Re: Introduction
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 23 Sep 84 16:07
PDT
To: RPG@SU-AI.ARPA
cc: mittal.PA, stefik.PA, bobrow.PA,Tom Bylander at Ohio State
<BYLANDER@RUTGERS.ARPA>
Richard,
I would be interested in being part of the
cl-object-oriented-programming discusion. I was forwarded your Intro
message by Tom Bylander at Ohio State.
danny
Glad to have you in on the discussion.
-rpg-
∂03-Oct-84 1518 MEEHAN@YALE.ARPA How constant are defconstants?
Received: from YALE.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 15:18:38 PDT
Received: by YALE-BULLDOG.YALE.ARPA; 3 Oct 84 18:11:59 EDT (Wed)
Message-Id: <8410032211.AA00370@YALE-BULLDOG.YALE.ARPA>
Date: Wed, 3 Oct 84 17:57:19 EDT
From: Jim Meehan <Meehan@YALE.ARPA>
Subject: How constant are defconstants?
To: Common-Lisp@SU-AI.ARPA
The Manual, page 68:
DEFCONSTANT is like DEFPARAMETER but does assert that the value
of the variable "name" is fixed and does license the compiler to
build assumptions into programs being compiled. (However, if the
compiler chooses to replace references to the name of the constant
by the value of the constant in code to be compiled, perhaps in
order to allow further optimization, the compiler must take care
that such "copies" appear to be EQL to the object that is the actual
value of the constant. For example, the compiler may freely make
copies of numbers but must exercise care when the value is a list.)
Suppose I say
(DEFCONSTANT *PLANETS*
'(MERCURY VENUS EARTH MARS JUPITER SATURN URANUS NEPTUNE PLUTO))
[and assume I got those in the right order]. It is now presumably
an error to say
(SETQ *PLANETS* x)
but what about
(SETF (CAR *PLANETS*) x) ?
It would seem problematic, since the compiler might want to compile
(CAR *PLANETS*) or (NTH 0 *PLANETS*) as 'MERCURY, just as it might
want to compile (CAR '(A B C)) as 'A.
For simple constants like that, the SETF seems unreasonable, but what's
a good way to create an array that is very expensive to initialize
(i.e., where computing the initial values takes a long time), and which
should be "read-only" thereafter (a la DEFSTRUCT)? I'm using
(DEFCONSTANT *THE-DATA* (MAKE-ARRAY ...))
followed by lots of
(SETF (AREF *THE-DATA* ...) <long computation>)
forms, but that looks strange. I'd like constant references into
*THE-DATA* to be replaced by the appropriate values, if possible, but
I'm really more interested in the read-only nature of the array itself.
-------
∂03-Oct-84 1654 RAM@CMU-CS-C.ARPA How constant are defconstants?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 16:49:26 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Wed 3 Oct 84 19:49:40-EDT
Date: Wed, 3 Oct 1984 19:49 EDT
Message-ID: <RAM.12052592778.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Jim Meehan <Meehan@YALE.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: How constant are defconstants?
In-reply-to: Msg of 3 Oct 1984 17:57-EDT from Jim Meehan <Meehan at YALE.ARPA>
Although defconstants are second-rate constants as compared to
literal constants inline in code, I think that previous decisions
forbidding modification of constants would apply here. In any case,
you can obtain the desired effect by specifying the contents at the
time the array is created:
(defconstant the-data (make-array n :initial-contents
(list <long-computation> ...)))
Rob
∂03-Oct-84 1721 FAHLMAN@CMU-CS-C.ARPA How constant are defconstants?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 17:17:57 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 3 Oct 84 20:18:15-EDT
Date: Wed, 3 Oct 1984 20:18 EDT
Message-ID: <FAHLMAN.12052597997.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Jim Meehan <Meehan@YALE.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: How constant are defconstants?
In-reply-to: Msg of 3 Oct 1984 17:57-EDT from Jim Meehan <Meehan at YALE.ARPA>
Jim,
The following is my own view on this issue. If anyone out there in
net-land disagrees, speak up.
The concept of enforced read-only data structures is not included in
Common Lisp, because implementations on some machines and on some
operating systems just couldn't hack that without an unacceptable
penalty in performance.
It "is an error" to mess with something declared to be a constant, which
means that the compiler can play various tricks, but doesn't have to. An
implemenations could build such a structure in some sort of read-only
space and signal an error if you try to alter it, but again it doesn't
have to. The same is true with :READ-ONLY slot options in Defstruct --
all this really guarantees is that no SETF form is created for this
slot.
So if you want to create a read-only structure that guarantees to signal
an error if you touch it, there may be a way to do this in some
implemenations, but there's no way to do this in portable Common Lisp.
You might just as well create your structure with DEFVAR.
-- Scott
∂03-Oct-84 2114 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 3 Oct 84 21:14:28 PDT
Date: 4 Oct 1984 00:14-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA
Cc: squires@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, shiel.pa@XEROX.ARPA
Cc: kahn@USC-ISI.ARPA
Message-ID: <[USC-ISI.ARPA] 4-Oct-84 00:14:13.SQUIRES>
In-Reply-To: <FAHLMAN.12052389510.BABYL@CMU-CS-C.ARPA>
This is a *VERY* important issue because it involves the health
of the community at a critical time in its growth. I hope that
it was clear at the recent Common LISP meeting (or future of LISP
meeting if you perfer) that DARPA sees Common LISP as solving
what it preceives to be a significant problem in managing the
delivery of the new generation of technology that will be
produced by the Strategic Computing Program. DARPA needs to have
maximal particpation of the community and wants to make use of
the accumulated organic knowledge base. In general, we believe
some mild constraints will significantly increase the gain of the
technology system. However, at any point in time, I believe that
we should use only the minimal constraints to achieve the desired
effect to insure that we to not significantly adversely affect
the rate of progress of the community for a significant period of
time. Since change always requires a period of transition, we
must carefully manage the rate of change, identify the community
affected, and insure that each new stage provides benefit to the
desired community.
I am very sympathetic to the needs of the people in the trenches.
You may be interested to learn that I spent over ten years in
those trenches. I worked in a research environment with
extraordinary computing resources and had essentually my own
PDP10 and later DEC System 20, high resolution graphics including
color, advanced workstations, XEROX STARS, Dandilions, and
Symbolics 3600s. I used a variety of dialects of LISP including
INTERLISP, and a variety of related languages and their
environments including MDL and ECL. Warren T would have been
right a home. I spent almost all my time developing rapid
prototypes for a variety of problem domains and extending the
environments to improve my performance. My intention in making
these personal remarks is not to brag, but to make it clear that
I have a deep appreciation for the needs of the people that are
actually developing the new generation and the importance of
listening to them very carefully. I know how much it meant to me
to know that people were listening to my needs and how painful it
was when "others" imposed almost anything that did not make sence
at the time (the pain must be worth the gain and the interaction
must have a rapid reaction).
The point is, I very much want to hear what the community has to
say on this issue and make sure that the right thing happens from
both its point of view and DARPA's. I believe that I have some
experience which will help make me very sensitive to the issues.
Before, I say any more, I would like to hear more...
∂04-Oct-84 0414 @MIT-MC:rwg%SPA-NIMBUS@SCRC-STONY-BROOK malnumeracy
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 04:13:43 PDT
Received: from SPA-RUSSIAN by SPA-Nimbus with CHAOS; Thu 4-Oct-84 01:27:16-PDT
Date: Thu, 4 Oct 84 01:24 PDT
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
Subject: malnumeracy
To: "common-lisp@SU-AI"@MIT-MC.ARPA
Supersedes: The message of 25 Sep 84 22:31-PDT from Bill Gosper <rwg at SPA-NIMBUS>
In aluminum edition, p. 18, 3.1010299957f-1 should be 3.010299957f-1.
On p. 67, the comment in (defun discriminant . . .) is wrong unless
the third sentence is preconditioned with "If a, b, and c are real,".
∂04-Oct-84 0544 @SU-SCORE.ARPA:Moon@SCRC-QUABBIN.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 05:44:27 PDT
Received: from SCRC-QUABBIN.ARPA (MIT-MC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 05:43:10-PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 87136; Mon 1-Oct-84 14:19:52-EDT
Redistributed-date: Mon, 1 Oct 84 14:20 EDT
Redistributed-to: Rem%IMSSS@SU-SCORE.ARPA,
COMMON-LISP%SU-AI@SU-SCORE.ARPA
Redistributed-date: Thu, 27 Sep 84 23:49 EDT
Redistributed-to: Rem%IMSSS@SU-SCORE.ARPA,
COMMON-LISP%SU-AI@SU-SCORE.ARPA
Date: Mon, 24 Sep 84 16:56 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Subject: Questions about specification and possible implementations
To: Rem%IMSSS@SU-SCORE.ARPA
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: The message of 23 Sep 84 20:52-EDT from Rem at IMSSS
Supersedes: <840924165534.2.MOON@EUPHRATES.SCRC.Symbolics>
Message-ID: <840924165603.3.MOON@EUPHRATES.SCRC.Symbolics>
Date: 23 Sep 1984 1752-PDT
From: Rem@IMSSS
In Common LISP there seems to be a strong dichotomy between functions
(all arguments evaluated before call) and macros&SpecialForms, almost
to the point of forbidding implementors to jump across the barrier.
Yet some functions with all the &OPTIONAL and &KEY arguments may be
difficult or inefficient to implement as true functions, and thus may
be implemented as FEXPRs in the interpretor and MACROs in the
compiler.
It is impermissible for an implementation to implement something documented
as a function as something other than a function. This doesn't rule out
compiler optimizations, of course, and all the implementations I know about
do compiler optimizations for the hairier and most common functions with
&KEY arguments.
The book says the set of special forms is fixed and no way is provided
to make new ones. But is any way provided to define some of the
special forms from LISP level in the first place, or must all be
handcoded in assembly language or C etc.? Is any way provided to
install bugfixes in special forms by overlaying the old definition
with a new one?
This is an issue for each implementation to address. The Common Lisp language
is a portable subset, not a complete implementation. To take one example, in
our implementation the interpreter routines for all of the special forms are
defined in Lisp, using a special-form-defining-special-form that you won't find
in the Common Lisp manual.
The reason it would be inutile to provide a portable way to define special forms
is that they have to be defined for both the interpreter and the compiler.
While it's (almost) easy to define portable extensions to the interpreter, there
is a wide variation in compiler techniques. Trying to standardize this would be
a monumental task, and probably doomed anyway since compiler techniques are
often dictated by the underlying hardware.
At the front of the chapter on numbers it claims:
(LET ((X Z) (Y Z))
(EQ X Y))
may be false if the value of Z is a number. I can't see a mechanism
for this in any reasonable LISP unless Z is not only presently a
number but has been declared a number and this is compiled code which
represents the value of Z as a machine number instead of a LISP
object, whereas X and Y are undeclared and thus LISP objects, so new
objects must be constructed for X and Y to hold the value Z, and these
new objects won't be EQ to each other. But could somebody who really
knows tell me what the true explanation is?? The book leaves this a
complete mystery.
Try the following example in pdp10 Maclisp (compiled without declarations).
(defun tst (z)
(let ((x z) (y z))
(eq x y)))
(defun tst2 (a b)
(tst (+ a b)))
(tst2 1234567 -1) => nil
I don't think the book needs to explain the inner workings of this. Common Lisp,
as a portable subset language, is allowed to contain freedoms for implementors
even if no current implementors exploit those freedoms, if it's reasonable to
assume that in the future someone may need those freedoms.
Minor questions:
In the introductory chapter, the Common-LISP book says semicolon
causes all characters up to eol to be discarded, but doesn't say
whether eol is kept or discarded.
A comment is equivalent to whitespace. In Lisp syntax it doesn't matter
whether whitespace is made out of spaces, carriage returns, or something
else, it just serves to separate tokens.
Ditto, doesn't say which characters inside "" are automatically
letterified and which have their usual semantic effects and thus need
explicit letterification to be treated as string text.
Huh?
Ditto, backslash at end of line does what? (Illegal, quote just the
next character which may be half of a crlf on some systems, quote the
eol token always?)
This is a good issue. From the discussion on page 22 I think it is supposed to
give a Newline character.
Bug in the manual: the word "newline" does not appear in the index.
Ditto, vertical-bar, same questions as for "".
(If above questions are answered elsewhere in manual, need pointer
from intro to where info given?)
When COPY-SYMBOL is done, the pnames will be the same, but will they
be EQ or just EQUAL?
Presumably this should be undefined since there is little to be gained by
defining it one way or the other and an implementation might want to do
something strange. After all, it is not even defined whether calling
SYMBOL-NAME twice on the -same- symbol yields EQ values!
The book doesn't say what (/ 1 0) does. Is it an error, or does it
signal an error, or does it return the ratio of 1/0 as a way of
representing infinity, or what?
Good question. There are no infinities in the standard numbers of Common Lisp,
so it can't be required to return 1/0. My guess is that Common Lisp does not
rule out a particular implementation deciding to return 1/0. In other words
it "is an error" -- portable programs should not depend on what happens, and
different implementations might do different things.
If NIL is an element of an assoc list, does this element get skipped
over by ASSOC et al or is it a stop flag?
Second to last paragraph on page 279.
How are the axis numbers of an array numbered, that is if you
create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0)
return 3 or 7?
Good point. It returns 3, but I don't see anything that says that explicitly.
∂04-Oct-84 0544 @SU-SCORE.ARPA:Moon@SCRC-QUABBIN.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 05:44:48 PDT
Received: from SCRC-QUABBIN.ARPA (MIT-MC.ARPA.#Internet) by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 05:43:35-PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 87137; Mon 1-Oct-84 14:20:02-EDT
Redistributed-date: Mon, 1 Oct 84 14:20 EDT
Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Redistributed-date: Thu, 27 Sep 84 23:49 EDT
Redistributed-to: COMMON-LISP%SU-AI@SU-SCORE.ARPA
Date: Mon, 24 Sep 84 16:55 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Subject: Questions about specification and possible implementations
To: Rem@IMSSS
cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: The message of 23 Sep 84 20:52-EDT from Rem at IMSSS
Message-ID: <840924165534.2.MOON@EUPHRATES.SCRC.Symbolics>
Date: 23 Sep 1984 1752-PDT
From: Rem@IMSSS
In Common LISP there seems to be a strong dichotomy between functions
(all arguments evaluated before call) and macros&SpecialForms, almost
to the point of forbidding implementors to jump across the barrier.
Yet some functions with all the &OPTIONAL and &KEY arguments may be
difficult or inefficient to implement as true functions, and thus may
be implemented as FEXPRs in the interpretor and MACROs in the
compiler.
It is impermissible for an implementation to implement something documented
as a function as something other than a function. This doesn't rule out
compiler optimizations, of course, and all the implementations I know about
do compiler optimizations for the hairier and most common functions with
&KEY arguments.
The book says the set of special forms is fixed and no way is provided
to make new ones. But is any way provided to define some of the
special forms from LISP level in the first place, or must all be
handcoded in assembly language or C etc.? Is any way provided to
install bugfixes in special forms by overlaying the old definition
with a new one?
This is an issue for each implementation to address. The Common Lisp language
is a portable subset, not a complete implementation. To take one example, in
our implementation the interpreter routines for all of the special forms are
defined in Lisp, using a special-form-defining-special-form that you won't find
in the Common Lisp manual.
The reason it would be inutile to provide a portable way to define special forms
is that they have to be defined for both the interpreter and the compiler.
While it's (almost) easy to define portable extensions to the interpreter, there
is a wide variation in compiler techniques. Trying to standardize this would be
a monumental task, and probably doomed anyway since compiler techniques are
often dictated by the underlying hardware.
At the front of the chapter on numbers it claims:
(LET ((X Z) (Y Z))
(EQ X Y))
may be false if the value of Z is a number. I can't see a mechanism
for this in any reasonable LISP unless Z is not only presently a
number but has been declared a number and this is compiled code which
represents the value of Z as a machine number instead of a LISP
object, whereas X and Y are undeclared and thus LISP objects, so new
objects must be constructed for X and Y to hold the value Z, and these
new objects won't be EQ to each other. But could somebody who really
knows tell me what the true explanation is?? The book leaves this a
complete mystery.
Try the following example in pdp10 Maclisp (compiled without declarations).
(defun tst (z)
(let ((x z) (y z))
(eq x y)))
(defun tst2 (a b)
(tst (+ a b)))
(tst2 1234567 -1) => nil
I don't think the book needs to explain the inner workings of this. Common Lisp,
as a portable subset language, is allowed to contain freedoms for implementors
even if no current implementors exploit those freedoms, if it's reasonable to
assume that in the future someone may need those freedoms.
Minor questions:
In the introductory chapter, the Common-LISP book says semicolon
causes all characters up to eol to be discarded, but doesn't say
whether eol is kept or discarded.
A comment is equivalent to whitespace. In Lisp syntax it doesn't matter
whether whitespace is made out of spaces, carriage returns, or something
else, it just serves to separate tokens.
Ditto, doesn't say which characters inside "" are automatically
letterified and which have their usual semantic effects and thus need
explicit letterification to be treated as string text.
Huh?
Ditto, backslash at end of line does what? (Illegal, quote just the
next character which may be half of a crlf on some systems, quote the
eol token always?)
This is a good issue. From the discussion on page 22 I think it is supposed to
give a Newline character.
Bug in the manual: the word "newline" does not appear in the index.
Ditto, vertical-bar, same questions as for "".
(If above questions are answered elsewhere in manual, need pointer
from intro to where info given?)
When COPY-SYMBOL is done, the pnames will be the same, but will they
be EQ or just EQUAL?
Presumably this should be undefined since there is little to be gained by
defining it one way or the other and an implementation might want to do
something strange. After all, it is not even defined whether calling
SYMBOL-NAME twice on the -same- symbol yields EQ values!
The book doesn't say what (/ 1 0) does. Is it an error, or does it
signal an error, or does it return the ratio of 1/0 as a way of
representing infinity, or what?
Good question. There are no infinities in the standard numbers of Common Lisp,
so it can't be required to return 1/0. My guess is that Common Lisp does not
rule out a particular implementation deciding to return 1/0. In other words
it "is an error" -- portable programs should not depend on what happens, and
different implementations might do different things.
If NIL is an element of an assoc list, does this element get skipped
over by ASSOC et al or is it a stop flag?
Second to last paragraph on page 279.
How are the axis numbers of an array numbered, that is if you
create an array by (MAKE-ARRAY 3 5 7) then will (ARRAY-DIMENSION array 0)
return 3 or 7?
Good point. It returns 3, but I don't see anything that says that explicitly.
∂04-Oct-84 0817 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 08:16:51 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Oct 84 11:16:58-EDT
Date: Thu, 4 Oct 1984 11:16 EDT
Message-ID: <FAHLMAN.12052761607.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Stephen L. Squires" <SQUIRES@USC-ISI.ARPA>
Cc: fateman@UCB-VAX.ARPA, griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA,
ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, sheil.pa@XEROX.ARPA
Subject: World peace
In-reply-to: Msg of 4 Oct 1984 00:14-EDT from Stephen L. Squires <SQUIRES at USC-ISI.ARPA>
Steve,
I think this is a *VERY* important issue too. That's why I've spent
three rather intense years trying to make Common Lisp happen. My own
hope is that Common Lisp will continue to grow in such a way that it
becomes a standard that people embrace voluntarily, and that very few
"constraints" will be needed. This might take a little longer, but it
will be less disruptive during the period of transition and will leave
everyone feeling a lot better the day after. Carrots usually work
better than sticks when you want the donkey to keep pulling and don't
want to damage him. Everyone knows that the stick is out there, to be
used if all else fails.
In talking with people before and since the Monterey conference, I
think the big fear is that at some point in the too-near future DARPA
may lay down an inflexible blanket policy that would either require
people to write their code on a certified Common Lisp system, or would
prohibit them from buying equipment that does not support such a system.
A lot of people out there -- not just the people at Xerox -- are
frightened and incensed about this prospect. I'm sure it is DARPA's
intention to be flexible and reasonable, as always, but that sort of
thing gets lost in the rumor mill. One case in which someone feels that
he was unreasonably over-constrained and starts complaining about it can
throw everyone else into a lather.
Anyway, the set of positions I proposed in my previous note was intended
to be one way of setting up the minimum necessary constraints, and a way
that might go down a bit better than saying "we require all work to be
done Common Lisp, but will be reasonable in applying this requirement".
-- Scott
∂04-Oct-84 1008 fateman%ucbdali@Berkeley numbers, oh well.
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 10:08:38 PDT
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.31)
id AA25397; Thu, 4 Oct 84 10:09:46 pdt
Received: by ucbdali.ARPA (4.24/4.38)
id AA00759; Thu, 4 Oct 84 10:09:14 pdt
Date: Thu, 4 Oct 84 10:09:14 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8410041709.AA00759@ucbdali.ARPA>
To: Moon@SCRC-RIVERSIDE.ARPA, Rem@IMSSS
Subject: numbers, oh well.
Cc: common-lisp@su-ai
"There are no infinities in the standard numbers of Common Lisp"
(this is repeated at the bottom of page 202 of aluminum edition.)
is inconsistent with the statement on p 19 of the same
edition, "... should approximate IEEE proposed standard ..." which
has infinities. Keeping 1/0 is probably less trouble than making
it an error.
For those of you who might think that arithmetic has been settled in a
correct and standard way in CL, I think that what has happened is that
people who have practical experience with error analysis and scientific
support have "tuned out" on CL, since it attempts to set a pseudo-standard
which is at odds with the IEEE (nearly adopted) standard.
∂04-Oct-84 1231 Moon@SCRC-STONY-BROOK.ARPA applyhook
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:30:25 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 103716; Thu 4-Oct-84 15:24:51-EDT
Redistributed-date: Thu, 4 Oct 84 15:25 EDT
Redistributed-to: Common-Lisp@SU-AI.ARPA
Redistributed-date: Sun, 30 Sep 84 22:14 EDT
Redistributed-to: Common-Lisp@SU-AI.ARPA
Date: Wed, 26 Sep 84 23:05 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Subject: applyhook
To: Common-Lisp@SU-AI.ARPA
In-Reply-To: <840831202452.2.MOON@EUPHRATES.SCRC.Symbolics>,
The message of 7 Sep 84 19:00-EDT from WVANROGGEN at DEC-MARLBORO,
The message of 10 Sep 84 03:24-EDT from GSB at MIT-MC
Message-ID: <840926230531.1.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri, 31 Aug 84 20:24 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
APPLYHOOK should not take an &OPTIONAL ENV argument.
Similarly *APPLYHOOK* should receive two arguments, not three arguments.
An environment is not meaningful for the APPLY operation, only for the EVAL operation.
Does anyone disagree?
I won't bother everyone by including the whole conversation that resulted from this,
just the final messages.
Date: Fri 7 Sep 84 19:00:15-EDT
From: "Walter van Roggen" <WVANROGGEN@DEC-MARLBORO.ARPA>
Actually, I hadn't thought about the potential ambiguity of which
environment would be passed to the apply hook function; I had just
assumed that it would be the same as that passed to the eval hook
function immediately before.
It seems to me that the purpose of applyhook is to allow one to
examine the actual function and the actual arguments it's about to
be applied to. (I suppose you could get the effect of the applyhook
by using the evalhook and simulating the evaluator--but that's what
this mechanism should help avoid.) It's a lot easier to examine
the environment of the function when it is handed to you. On the other
hand you could argue that any debugging facility will always use both
evalhook and applyhook simultaneously, but that shouldn't be necessary.
Date: 10 September 1984 03:24-EDT
From: Glenn S. Burke <GSB @ MIT-MC>
I think we've safely established that in order to just function
properly, APPLYHOOK (and therefore the value of *APPLYHOOK*) does
not need to be given an environment argument.
As someone said, it makes no sense to pass one environment because
there are two involved. To me, that means we should pass BOTH
environments. After all, one of the purposes of having this is for
debugging, from user code. If we did not want this we wouldn't have
defined the hooks, just specified the existence of STEP like we have
TRACE. *APPLYHOOK* should be given TWO environments: one is the
current environment (as of when the hook is invoked -- like that given
to *evalhook*). The other is an environment object gleaned from the
function being applied. This is so that *applyhook* can examine
either one. Possibly in the case of compiled or globally defined
functions, the function-environment argument will be NIL, of course.
So, what i propose is this:
*APPLYHOOK* gets called on 4 arguments:
(1) the function being applied
(2) the list of arguments
(3) the environment of the function
(4) the current environment.
APPLYHOOK takes only arguments of the function, arguments, evalhookfn,
and applyhookfn. No environment argument at all -- the function
carries the environment with it. Evaluation of a lambda combination
((lambda ...) ...) passes a function made (as if) by evaluating
(function (lambda ...)).
The function-environment argument to *applyhook* is deliberately
redundant with the environment carried by the function, so that it may
be an environment object just like the current-environment argument,
and thus examined/whatever similarly.
I feel fairly strongly that to not pass these environments to
*applyhook* just because it looks now like we can get away with it
will unnecessarily restrict any sort of debugging extensions in the
future. And even within the present CL definition user code can do
things with them by passing them to EVAL.
This is probably right. Certainly you all talked me into believing the theory
that *applyhook* should be passed the environment in which the arguments
were evaluated, since some programs might need that and it's not easily accessible
otherwise.
As for whether the *applyhook* should also receive the environment in which forms
in the body of the function will be evaluated, my feeling is: maybe, but wouldn't
it be better to provide general facilities for accessing the various parts of
a function (that is, an applicable object; that is, anything that can be the
first argument to *applyhook* and also anything that can be the result of
SYMBOL-FUNCTION). These parts include at least the name, the environment, the
parameter list, and the body.
For now, in my system, I decided to compromise and implement what it says in the
manual (always a good default!). *applyhook* takes three arguments and
applyhook takes five arguments (one of which is optional). As for what the
manual doesn't say, the last argument to *applyhook* is the environment in which
the arguments were evaluated, the last argument to applyhook is ignored.
∂04-Oct-84 1248 JonL.pa@Xerox.ARPA Re: How constant are defconstants?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:48:04 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 12:47:27 PDT
Date: 4 Oct 84 12:47 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: How constant are defconstants?
In-reply-to: Jim Meehan <Meehan@YALE.ARPA>'s message of Wed, 3 Oct 84
17:57:19 EDT
To: Meehan@YALE.ARPA
cc: Common-Lisp@SU-AI.ARPA
I would assume that whereever one had written code like
(FOO *PLANETS*)
that he would get the same operational behaviour as if he had written
(FOO '(MERCURY VENUS EARTH MARS JUPITER SATURN URANUS NEPTUNE PLUTO))
PDP10 MacLisp made it possible to convert all such constants into
read-only areas -- with the view to catching unintended updates such as
your example
(SETF (CAR *PLANETS*) something)
but I'm sure that Common Lisp can't enforce such a protective mechanism
-- only permit it. Even MacLisp's solution is only partial, in that the
constants are writeable until the explicit call to "convert" everything
over.
Interlisp has gone to the other extreme -- not only is there lots of
existing code with runtime updates to compile-time constants, but in
Interlisp-10 there is even the weird SETN to update "numbers". E.g.
-> (SETQ TEM (SETQ PI 3.14))
3.14
-> (SETN PI 3.14159)
3.14159
-> TEM
3.14159
Happily, Interlisp-D, didn't perpetuate the SETN lossage, but there is
still a lot of resistance in the Interlisp community to giving up
updatability of "constants".
-- JonL --
∂04-Oct-84 1339 @SU-SCORE.ARPA:HEDRICK@RUTGERS.ARPA Re: Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 13:34:16 PDT
Received: from RUTGERS.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 13:23:02-PDT
Date: 4 Oct 84 16:24:40 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Questions about specification and possible implementations
To: Moon@SCRC-RIVERSIDE.ARPA
cc: Rem%IMSSS@SU-SCORE.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA
In-Reply-To: Message from "Moon@SCRC-RIVERSIDE.ARPA" of 24 Sep 84 16:56:00 EDT
I'm not sure I agree with the comment that all implementations will
optimize keyword functions. It is certainly true that one can easily
optimize them. However one of the nice things about Lisp is that
it is possible to redefine functions on the fly. This allows things
like TRACE, BREAK, and ADVISE, not to mention having users replace
standard functions with their own versions. If the compiler turns
(foo :bogus-key 1)
into
(foo-internal-form 1)
then the user can't redefine foo and get the expected result. Thus
I believe it to be a mistake to do these optimizations.
I'm sure that this is a minority opinion. Most of the people involved
in the Common Lisp language definition do not believe in this sort
of thing, just as they do not believe in interpreters. But there are
some implementors who want Common Lisp to be a dialect of Lisp.
-------
∂04-Oct-84 1340 KMP@MIT-MC *applyhook*
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 13:39:54 PDT
Date: 4 October 1984 16:37-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: *applyhook*
To: Moon @ SCRC-RIVERSIDE
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Wed 26 Sep 84 23:05 EDT from Moon at SCRC-RIVERSIDE.ARPA
By the way, in talking to GSB on this issue, I have been convinced to withdraw
my objection to having the *APPLYHOOK* handler take the env argument of the
caller. After all, if the arguments being inspected have been passed incorrectly,
it would be handy to be able to compute new ones using the old environment.
I agree with most of your remarks regarding creating ways of accessing
parts of functions (name, env, params for sure; I'm not sure about body --
not clear to me exactly how that differs from interpreted to compiled
code). Also, in the case of env, it may be the case that either the meaning of
that will have to be left vague or else optimization may suffer. eg, hypothesizing
that ENV-OF accessed a closure's environment, would
(LAMBDA (Y) ((LAMBDA (X) (EQ X (EVAL 'X (ENV-OF #'(LAMBDA () X))))) Y))
and (LAMBDA (Y) (EQ Y (EVAL 'X (ENV-OF #'(LAMBDA () Y)))))
be semantically equivalent expressions? In light of this, how exactly would
you want the ENV-OF function to be used such that this sort of problem did
not come up?
-kmp
∂04-Oct-84 1423 masinter.pa@Xerox.ARPA Re: How constant are defconstants?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:23:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 14:23:27 PDT
Date: 4 Oct 84 14:22 PDT
From: masinter.pa@XEROX.ARPA
Subject: Re: How constant are defconstants?
In-reply-to: JonL.pa's message of 4 Oct 84 12:47 PDT
To: JonL.pa@XEROX.ARPA
cc: Meehan@YALE.ARPA, Common-Lisp@SU-AI.ARPA
Your message puzzles me; I've not seen "lots of existing code with
runtime updates to compile-time constants".
In fact, compile time constants were only added to Interlisp in the
last couple of years (1981 or 1982, I believe), and didn't appear in the
1978 manual.
∂04-Oct-84 1458 @SU-SCORE.ARPA:WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 14:57:49 PDT
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 14:55:23-PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 4 Oct 84 17:44:27-EDT
Date: Thu, 4 Oct 1984 17:43 EDT
Message-ID: <WHOLEY.12052831948.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, Moon@SCRC-RIVERSIDE.ARPA,
Rem%IMSSS@SU-SCORE.ARPA
Subject: Questions about specification and possible implementations
In-reply-to: Msg of 4 Oct 1984 16:24-EDT from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
It is certainly alright to optimize BUILT-IN keyword functions, since "it is an
error" to redefine them; it is alright to "open code" CAR for the same reason.
If I were to put in code that tried to optimize ALL keyword functions, I would
transform your call
(foo :bogus-key 1)
into something like
(if (eq #'foo-intern-form '#<Function FOO-INTERNAL-FORM {75234}>)
(foo-internal-form 1)
(foo :bogus-key 1)),
where that quoted unreadable thing is what the caller thought FOO's
non-keywordized form was at the time of compilation. This is a correct
transformation even in the case that you're worried about, and can be done
efficiently on all machines I can think of. Those machines with hairy linkage
mechanisms could perhaps do it a wee bit more efficiently.
--Skef
∂04-Oct-84 1545 JonL.pa@Xerox.ARPA Re: How constant are defconstants?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 15:45:28 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 04 OCT 84 15:43:36 PDT
Date: 4 Oct 84 15:38 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: How constant are defconstants?
In-reply-to: masinter.pa's message of 4 Oct 84 14:22 PDT
To: masinter.pa@XEROX.ARPA
cc: JonL.pa@XEROX.ARPA, Meehan@YALE.ARPA, Common-Lisp@SU-AI.ARPA
Sorry, I wasn't fully clear. "compile-time constants", when mentioned
to the CommonLisp community, merely mean "constants", especially when
encountered by the compiler. The common lisp term for what you are
referring to is "Named constants" (sec 5.1.2 of manual), and I'm afraid
you've just confused the two.
The existing code with "runtime updates to compile-time constants"
occurs even in older Interlisp code like this:
(SETQ *FOO* (QUOTE (MY MESSAGE ABOUT *SOMETHING*)))
. . .
(RPLACA (CDDDR *FOO*) (QUOTE VARIABLES))
and in the context of the discussion, (QUOTE (MY MESSAGE ABOUT
*SOMETHING*)) is a "compile time" constant.
-- JonL --
∂04-Oct-84 1731 Moon@SCRC-QUABBIN.ARPA numbers, oh well.
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:29:35 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 88632; Thu 4-Oct-84 20:29:39-EDT
Date: Thu, 4 Oct 84 20:30 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: numbers, oh well.
To: Richard Fateman <fateman%ucbdali@UCB-VAX.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: <8410041709.AA00759@ucbdali.ARPA>
Message-ID: <841004203015.5.MOON@EUPHRATES.SCRC.Symbolics>
Date: Thu, 4 Oct 84 10:09:14 pdt
From: fateman%ucbdali@Berkeley (Richard Fateman)
"There are no infinities in the standard numbers of Common Lisp"
(this is repeated at the bottom of page 202 of aluminum edition.)
is inconsistent with the statement on p 19 of the same
edition, "... should approximate IEEE proposed standard ..." which
has infinities.
The first statement says that an implementation is not required to
provide infinities, and therefore portable programs cannot rely upon
infinite numbers. The second statement recommends that those
implementations that have a choice should approximate IEEE numbers in
their floating point, and thus some implementations are permitted and
even encouraged to have infinite floating point numbers. I fail to see
any inconsistency here.
Keeping 1/0 is probably less trouble than making it an error.
Floating point numbers and rational numbers are not the same.
Particular implementations of Common Lisp and the Common Lisp language
are not the same.
I think we've been through this discussion quite enough times before.
Let's work on something that matters.
For those of you who might think that arithmetic has been settled in a
correct and standard way in CL, I think that what has happened is that
people who have practical experience with error analysis and scientific
support have "tuned out" on CL, since it attempts to set a pseudo-standard
which is at odds with the IEEE (nearly adopted) standard.
I fail to find anything in the Common Lisp manual that forbids an implementation
to conform to the IEEE proposed standard. I fail to find anything in the Common
Lisp manual that requires me to change my machine, which currently conforms to
the IEEE proposed standard, and make it cease conforming to that standard.
Let's discuss something else.
∂04-Oct-84 1739 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:38:59 PDT
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 16:34:43-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 16:35:41 PDT
Date: 4 Oct 84 16:01 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Questions about specification and possible implementations
In-reply-to: Skef Wholey <Wholey@CMU-CS-C.ARPA>'s message of Thu, 4 Oct
84 17:43 EDT
To: Wholey@CMU-CS-C.ARPA
cc: HEDRICK@RUTGERS.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA,
Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA
Hmmm, I think this discussion is beating around an important "bush" --
namely *exactly* which of the functions in the Common Lisp spec is it
permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc
will not work? Additionally, there may be other functions for which
TRACE etc cannot work (there are a number of such functions in
Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who
accidentally stumbles across one, for his machine will rapidly take a
non-returnable vacation "South")
I see Hedrick's complaint as continuing evidence of the tension in this
community between the special-purpose microcoded machine adherents and
the general-purpose stock hardware men. I'm with Chuck in thinking that
it was a mistake to remove names of functions that are "there only for
compiler optimizations" -- as long as Common Lisp is going to run on
something other than a 3600 or a PERQ, more attention needs to be paid
to these needs. (i.e., when Chuck says "I believe it to be a mistake to
do these optimizations", I take him to mean that either you must compile
a call to the documented function, or else provide a documented name of
the right functionality that the user might put in his source code).
At one time, all such needs were swept into the bag of "it's only a
compiler optimization, put it in a DECLARE" -- remember the RPG Memorial
Vector Proposal -- but if these "compiler optimizations" are critically
essential to any realistic implementation on stock hardware . . .
Incidentally, your solution of dynamic testing is similar to many speed
optimizations that compilers sometimes emit (e.g., doing an open-coded
EQ check before actually calling EQUAL), but I'd had to see it applied
to all those "myriads" of functions that took any keyword -- think of
the code-size bloat!
-- JonL --
∂04-Oct-84 1746 @SU-SCORE.ARPA:WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 17:44:59 PDT
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 17:42:50-PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 4 Oct 84 20:43:06-EDT
Date: Thu, 4 Oct 1984 20:43 EDT
Message-ID: <WHOLEY.12052864666.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: JonL.pa@XEROX.ARPA
Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA,
Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA
Subject: Questions about specification and possible implementations
Date: Thursday, 4 October 1984 19:01-EDT
From: JonL.pa at XEROX.ARPA
Hmmm, I think this discussion is beating around an important "bush" --
namely *exactly* which of the functions in the Common Lisp spec is it
permissible to open-code in such a way that TRACE, BREAK, ADVISE, etc
will not work?
(DECLARE (NOTINLINE FOO)) is the way to make FOO traceable regardless of what
the compiler might do. All implementations should grok that.
Additionally, there may be other functions for which
TRACE etc cannot work (there are a number of such functions in
Interlisp-D -- QUOTE comes to mind -- and woe betide the poor loser who
accidentally stumbles across one, for his machine will rapidly take a
non-returnable vacation "South")
QUOTE is a special form. The Common Lisp specification of TRACE indicates that
it may be used to trace functions, not macros or special forms. I agree that
tracing macros and special forms can be useful, but restricting TRACE to
functions is an elegant way to avoid that problem. Indeed, there are some
functions that probably can't be traced, but I believe the encapsulation code
can figure out when it's being invoked recursively. Our TRACE endeavors to do
this. Making the encapsulation code be compiled (easy and fun with lexical
closures!) avoids the lossage that can happen when one traces EVAL, for
example.
I see Hedrick's complaint as continuing evidence of the tension in this
community between the special-purpose microcoded machine adherents and
the general-purpose stock hardware men. I'm with Chuck in thinking that
it was a mistake to remove names of functions that are "there only for
compiler optimizations" -- as long as Common Lisp is going to run on
something other than a 3600 or a PERQ, more attention needs to be paid
to these needs. (i.e., when Chuck says "I believe it to be a mistake to
do these optimizations", I take him to mean that either you must compile
a call to the documented function, or else provide a documented name of
the right functionality that the user might put in his source code).
If I were also involved in doing a stock-hardware implementation (which I am),
I don't think I'd decide to do these things differently. I assume you meant
that this quick check could be part of a microcoded instruction. If I
implemented the scheme I outlined in my previous message, I would do so without
introducing any new macroinstruction. I don't think it's worth the microcode.
At one time, all such needs were swept into the bag of "it's only a
compiler optimization, put it in a DECLARE" -- remember the RPG Memorial
Vector Proposal -- but if these "compiler optimizations" are critically
essential to any realistic implementation on stock hardware . . .
Almost all of the "compiler optimizations" that make vector hacking cheap on
stock hardware are very easy to do if the right information is around at the
right time. Declarations are important in Common Lisp on stock hardware; if
you're implementing Common Lisp on stock hardware, your compiler should be
structured so that the information from the declarations is easily accessible
in your code generator and optimizers.
Incidentally, your solution of dynamic testing is similar to many speed
optimizations that compilers sometimes emit (e.g., doing an open-coded
EQ check before actually calling EQUAL), but I'd had to see it applied
to all those "myriads" of functions that took any keyword -- think of
the code-size bloat!
If you're concerned about code size, do (DECLARE (OPTIMIZE SPACE)). I've spent
a great deal of time in the past few weeks staring at assembly code listings,
and I'm pretty sure that such a test on function calls to keywordized functions
would not contribute significantly to code size. There are "myriads" of
functions that take keyword args, but I don't think there are "myriads" of
calls to those functions.
--Skef
∂04-Oct-84 1828 Moon@SCRC-QUABBIN.ARPA Questions about OPEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 18:27:41 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 88658; Thu 4-Oct-84 21:27:49-EDT
Date: Thu, 4 Oct 84 21:28 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Questions about OPEN
To: "Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
cc: common-lisp@SU-AI.ARPA
In-Reply-To: The message of 3 Oct 84 09:26-EDT from "Robert (LISPer 68K)Heller" <heller%umass-cs.csnet at CSNET-RELAY>
Message-ID: <841004212821.9.MOON@EUPHRATES.SCRC.Symbolics>
Date: Wed, 3 Oct 84 08:26 EST
From: Robert (LISPer 68K)Heller <heller%umass-cs.csnet@csnet-relay.arpa>
I have some questions about what the function OPEN returns if
:DIRECTION is :PROBE:
1) if the file exists, does OPEN return a closed stream?
Well, it returns a stream that doesn't support any I/O operations, just things
like file-write-date, file-author, file-length, and truename. This could be
implemented as a special kind of stream or as a closed stream.
Interestingly enough, the manual says that each of those four functions
is only allowed for an open stream. Presumably this means to imply that you
cannot use them on a stream returned by a probe-open. This in turn implies
that probe-open might as well have been defined to return simply true or
false.
I contend that :direction :probe should never have been put into Common Lisp
and only the probe-file function ought to exist. In some implementations,
ours for instance, probe-file is implemented by calling open with the
:direction :probe option, but I think that is an internal interface, not
something that should be visible in the Common language.
On the other hand, in some file systems the write-date, author, length,
and truename cannot be determined for an output file until the file is
closed, because the file system assigns them at that time. This
suggests that it was a mistake for the manual to require that the stream
passed to these functions be open. They ought to accept a stream that
resulted from probe-open and also a stream that has been closed with the
close function.
2) if the file does not exist and :IF-DOES-NOT-EXIST is
:CREATE, what does OPEN do? create an empty and return a
closed stream?
We signal an error for an illegal combination of options. I can't tell
whether the manual rules that out or not.
Is Guy, or anyone, still recording possible ambiguities or errors in the
manual for later correction? I don't plan to follow this up myself.
∂04-Oct-84 1911 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:11:35 PDT
Date: 4 Oct 1984 22:11-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: SQUIRES@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA
Cc: sheil.pa@XEROX.ARPA
Message-ID: <[USC-ISI.ARPA] 4-Oct-84 22:11:09.SQUIRES>
In-Reply-To: <FAHLMAN.12052761607.BABYL@CMU-CS-C.ARPA>
I agree with the approach that you are advocating and strongly agree
that Common LISP should suceed on its merits. It is up to DARPA do
do what it can to support the process and "preserve world pease".
The time has come for the rumor mill to stop generating misleading
rumors for whatever purposes. What would be an effective way to
state the case and replace the rumors with constructive facts?
∂04-Oct-84 1914 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:14:13 PDT
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Thu 4 Oct 84 19:11:50-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 OCT 84 19:11:56 PDT
Date: 4 Oct 84 19:11 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Questions about specification and possible implementations
In-reply-to: Skef Wholey <Wholey@CMU-CS-C.ARPA>'s message of Thu, 4 Oct
84 20:43 EDT
To: Wholey@CMU-CS-C.ARPA
cc: JonL.pa@XEROX.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA,
HEDRICK@RUTGERS.ARPA, Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA
NOTINLINE isn't the issue -- it's knowing *who* needs to be so protected
when one wants to ensure traceability. In fact, many major Interlisp-D
operations are ambiguous at the compiler level -- the compiler merely
emits an opcode with *may or may not* call the function of the
corresponding name.
I agree -- it's too bad that special forms and macros aren't traceable.
But as you recognize, that isn't the source of the unTRACEability
problem -- it's when the encapsulation function somehow depends on the
function being traced. If encapsulation functions were always compiled
(by possibly a super-fast non-optimizing compiler) then the space of
untraceables would diminish dramatically. PDP10 MacLisp tried to do
something like that -- using "hidden" copies of the systems functions
which it used (like PRINT ...). Unfortunately it, like Interlisp,
didn't "hide" QUOTE.
Re the space cost of "double-compilation" (may I call the scheme you
proposed that? the one to emit both code sequences for open and for
closed formats, which is toggled by a runtime switch), and you comment
". . . but I don't think there are 'myriads' of calls to those
functions". Did you examine the SpiceLisp implementation, or user
application programs?
-- JonL --
∂04-Oct-84 1934 RAM@CMU-CS-C.ARPA Questions about OPEN
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 19:34:12 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Thu 4 Oct 84 22:33:23-EDT
Date: Thu, 4 Oct 1984 22:33 EDT
Message-ID: <RAM.12052884746.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Cc: common-lisp@SU-AI.ARPA,
"Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
Subject: Questions about OPEN
In-reply-to: Msg of 4 Oct 1984 21:28-EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
Well, if it's constructive to flame about the file system
interface at this point, then I will add that I agree the :direction
:probe is silly. I also believe that requiring all of the
file/pathname functions to accept streams as arguments is silly. It
seems to me that this symbol/namestring/stream/pathname foolishness is
a result of the confusion between streams and pathnames and strings
and symbols that is present in earlier lisps because they lack some of
the above.
I think that it is totally silly to suggest that these operations
work on closed streams, since a closed stream can have no semantics
other than possibly its name, which could be better represented by a
pathname. If we really want to do this sort of thing, then we should
define a File-Stream-Name function that returns the pathname
associated with a file stream so that people can get the name from a
stream.
My opinon may be slightly biased by the lack of any concept of an open
file in the Sesame filesystem that underlies Spice Lisp.
Rob
∂04-Oct-84 2017 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 20:16:59 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Oct 84 23:16:47-EDT
Date: Thu, 4 Oct 1984 23:16 EDT
Message-ID: <FAHLMAN.12052892645.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Stephen L. Squires" <SQUIRES@USC-ISI.ARPA>
Cc: fateman@UCB-VAX.ARPA, griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA,
ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, sheil.pa@XEROX.ARPA
Subject: World peace
In-reply-to: Msg of 4 Oct 1984 22:11-EDT from Stephen L. Squires <SQUIRES at USC-ISI.ARPA>
I'm glad you agree with the sort of approach I suggested. Once DARPA is
ready to propose a specific policy, the quickest way to replace the
rumors with facts would be to post something to COMMON-LISP @ SU-AI.
Not everyone concerned is on this mailing list, but that would certainly
get the word to enough people at once to kill off any rumors.
I would suggest, however, that any policy proposals be discussed and
debugged within this more limited forum first, not because we want to be
secretive, but just because it is impossible to discuss so tricky an
issue before a much larger group.
So far, I've heard nothing from the other recipients of this proposal
about whether they think it's a reasonable way to go. I've tried to
come up with a plan that minimizes the negative impact of the Common
Lisp standardization effort on the communities currently tied to other
Lisps, but only they can tell us whether I've succeeded. I may be blind
to some of their problems.
-- Scott
∂04-Oct-84 2033 FAHLMAN@CMU-CS-C.ARPA Questions about OPEN
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 20:33:07 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 4 Oct 84 23:27:32-EDT
Date: Thu, 4 Oct 1984 23:27 EDT
Message-ID: <FAHLMAN.12052894597.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: Questions about OPEN
In-reply-to: Msg of 4 Oct 1984 22:33-EDT from Rob MacLachlan <RAM>
I agree with both Moon's and Maclachlan's comments on the stream stuff.
This seems to be one area in which we never got things untangled
properly. Does anyone see a problem with the changes Rob proposes? If
not, we should cast these into a formal proposal and have a vote -- I
guess that's how we make changes official these days.
-- Scott
∂04-Oct-84 2212 Moon@SCRC-STONY-BROOK.ARPA Questions about OPEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 22:11:42 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 104028; Fri 5-Oct-84 01:11:53-EDT
Date: Fri, 5 Oct 84 01:12 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Questions about OPEN
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
cc: common-lisp@SU-AI.ARPA,
"Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
In-Reply-To: <RAM.12052884746.BABYL@CMU-CS-C.ARPA>
Message-ID: <841005011201.3.MOON@EUPHRATES.SCRC.Symbolics>
Date: Thu, 4 Oct 1984 22:33 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
Well, if it's constructive to flame about the file system
interface at this point, then I will add that I agree the :direction
:probe is silly. I also believe that requiring all of the
file/pathname functions to accept streams as arguments is silly. It
seems to me that this symbol/namestring/stream/pathname foolishness is
a result of the confusion between streams and pathnames and strings
and symbols that is present in earlier lisps because they lack some of
the above.
Not exactly. Many of these functions, when applied to a stream, do something
slightly different than when applied to a pathname. Specifically, they
operate on the exact file to which the stream is attached, which may not be
the same file as the one you would get if you used the name by which the
stream was opened (someone may have renamed something in the meantime, a new
version of the file may have been created in the meantime, or the file to
which the stream is attached may not be accessible any other way [in some
file systems] because it is a newly-created output file, for example).
This is an example of message-passing / generic-functions / object-oriented
programming sneaking into Common Lisp in the guise of ordinary functions.
I don't think that's bad. Historically I/O -is- where it tends to strike first.
I think that it is totally silly to suggest that these operations
work on closed streams, since a closed stream can have no semantics
other than possibly its name, which could be better represented by a
pathname.
Ours have slightly more semantics than that; they have a property list
of certain properties of the file that they used to be connected to when
they were open. The main reason for this is what I mentioned before
about some file systems not knowing the truename (among other properties)
of an output file until it is closed.
If we really want to do this sort of thing, then we should
define a File-Stream-Name function that returns the pathname
associated with a file stream so that people can get the name from a
stream.
Isn't that what the pathname and truename functions do, when applied to
a stream? (There are two possible pathnames you could want from a stream,
the one it was opened with and the one it is actually connected to).
My opinon may be slightly biased by the lack of any concept of an open
file in the Sesame filesystem that underlies Spice Lisp.
One example of the enormous diversity of file systems that we are trying
to squeeze into a single model so we can write portable programs.
I do think that :direction :probe should be flushed, on the grounds that it
is exposing an implementation-dependent mechanism and that the portable
aspects of it are already available through probe-file. I also think that
not all of Symbolics' experience in dealing with incompatible file systems
in a generic way was distilled into the writeup in the Common Lisp manual,
and a future second edition should incorporate more of that as well as
other people's experiences, to make user's file-processing programs more
likely to be truly portable.
∂04-Oct-84 2347 RAM@CMU-CS-C.ARPA Questions about OPEN
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 23:47:13 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 5 Oct 84 02:46:06-EDT
Date: Fri, 5 Oct 1984 02:46 EDT
Message-ID: <RAM.12052930752.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Cc: common-lisp@SU-AI.ARPA,
"Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
Subject: Questions about OPEN
In-reply-to: Msg of 5 Oct 1984 01:12-EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
I concede those points, and was aware that, for example,
Rename-File has somewhat different semantics on a stream than it has
on the name. I can deal with that, since all we have to do in Spice
Lisp to implement this is change the name we write the data out as
when we close the file. You clarification, however, seems to assume
that there is some concept of file identity independent of the file
name. This is not true in Sesame, and is probably not true in many
file systems. There is no way to keep track of a file across
renamings and other operations.
I guess we have several options here:
1] We can leave the manual the way it is, with the semantics of use
of streams vis a vis pathnames largely unspecified. This would permit
implementations to do arbitrarily whizzy things, but would make the
use of stream arguments difficult in portable code, and thus dubious
as a Common Lisp feature.
2] We can try to define the semantics. This course is fraught with
peril, since capabilities of operating systems differ wildly.
3] We can punt and remove them.
In many cases, the CLM seems to do 1, on the grounds that it would
be nice to have a standard way to say X, given that X is possible. I
have mixed feelings about this. In the case of the
:If-Exists/:If-Does-Not-Exist arguments to Open, it seems reasonable,
since even an inconceivably brain-damaged OS should be able to provide
some sort of reasonable default action, and the program will still
work. In the case of Rename-File, though, the call will error out,
(or worse, simply quietly fail) if the capability to rename open files
doesn't exist. A program counting on this feature would not work, and
thus would not be portable.
I think that this business of streams-as-files is especially
problematical in our implementation, since there is no "file attached
to the stream", only a memory buffer area where you are building up a
file that you may write out when the stream is closed. Sesame is in
fact a system such as you mentioned, in which it is impossible to
determine the truename of an "open" file, since the version number is
determined when the file is written. It seems to me that this
argument could just as easily be used to support the position that the
feature should be flushed as being impossible to specify in a
implementation independent fashion.
For us, the Probe-File and Truename functions are the most
annoying. The Rename-File and Delete-File functions, which don't have
to work right according to the CLM, are easily implementable.
Currently, our implementation does not obey the
(probe-file (open ...)) => t
invariant. We could dummy it up so that it would return the pathname
that it thinks it is going to write the file out to, but that would
cause anomalous behavior such as:
(probe-file stream) => <some pathname>
(probe-file <some-pathname>) => nil
Rob
∂05-Oct-84 1018 HEDRICK@RUTGERS.ARPA Re: Questions about OPEN
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 10:18:13 PDT
Date: 5 Oct 84 13:09:40 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Questions about OPEN
To: RAM@CMU-CS-C.ARPA
cc: Moon@SCRC-RIVERSIDE.ARPA, common-lisp@SU-AI.ARPA,
heller%umass-cs.csnet@CSNET-RELAY.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of 5 Oct 84 02:46:00 EDT
On the DEC-20 it would certainly be better to maintain the distinction
between filename and stream. A common strategy for an editor is to
write a new copy of a file with a temporary file name, close it, and
then rename it on top of the original. This minimizes the probability
of damage in a crash. One would prefer to use the same JFN for this
entire process. A JFN is a small integer that is a handle on a file.
If you keep the JFN active, you are sure that nobody else is going to
rename the file out from under you or do anything else nefarious.
This is easy if all of the operations can be done on streams. My
feeling is that the distinction makes sense on some OS's, and on
others causes no harm (other than extra code), so it should be kept.
-------
∂05-Oct-84 1250 RAM@CMU-CS-C.ARPA Questions about OPEN
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 12:50:10 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 5 Oct 84 15:49:20-EDT
Date: Fri, 5 Oct 1984 15:49 EDT
Message-ID: <RAM.12053073333.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: common-lisp@SU-AI.ARPA, heller%umass-cs.csnet@CSNET-RELAY.ARPA,
Moon@SCRC-RIVERSIDE.ARPA
Subject: Questions about OPEN
In-reply-to: Msg of 5 Oct 1984 13:09-EDT from Charles Hedrick <HEDRICK at RUTGERS.ARPA>
You don't seem to follow what Moon and I were saying about
truename (and probe-file) -- in some filesystems it is TOTALLY
IMPOSSIBLE with *any* amount of code to implement the semantics
described in the manual. The usual cause for this is that the version
number is unknown until the stream is closed. A secondary problem is
that in some OS'es, a newly created file does not exist in the
filesystem namespace until it is closed.
In any case, rename-file can only be done on *open* files
according to the CLM. And if you keep the JFN around for every file
stream there has ever been, when are you going to do the RLJFN?
Rob
∂05-Oct-84 1341 @SU-SCORE.ARPA:HANDERSON@CMU-CS-C.ARPA Aside about encapsulations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 13:33:30 PDT
Received: from CMU-CS-C.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 13:03:44-PDT
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Fri 5 Oct 84 15:29:00-EDT
Date: Fri, 5 Oct 1984 13:35 EDT
Message-ID: <HANDERSON.12053049027.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: JonL.pa@XEROX.ARPA
Cc: COMMON-LISP%SU-AI@SU-SCORE.ARPA, HEDRICK@RUTGERS.ARPA,
Moon@SCRC-RIVERSIDE.ARPA, Rem%IMSSS@SU-SCORE.ARPA, Wholey@CMU-CS-C.ARPA
Subject: Aside about encapsulations
In-reply-to: Msg of 4 Oct 1984 22:11-EDT from JonL.pa at XEROX.ARPA
I just wrote an encapsulation package for Spice Lisp that can trace an
arbitrary setfable location. The encapsulation is a closure that does all the
real work (normally, calling the encapsulation functions, but also adding and
deleting encapsulation functions and deleting itself). Most implementations
could probably use this to encapsulate the expansion function for a macro [we
use (MACRO . <function>) on the function cell]. This encapsulation can wrap
the result of the expansion with arbitrary forms, in order to "encapsulate the
macro call." [Probably not desirable, since compiled code would contain the
encapsulation...] Someday soon I'll finish the job and write a trace package.
The thing about encapsulating special forms is that the encapsulation function
has to be a special form. All the information could be stored elsewhere, but
you have to know which special form you're talking about. I haven't
thought up a way to do this, unless we add closure special forms to the system
(looks hard) or the encapsulation function examines the stack (eeew grossss).
Anybody?
-- Steve
∂05-Oct-84 1344 HEDRICK@RUTGERS.ARPA Re: Questions about OPEN
Received: from RUTGERS.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 13:37:34 PDT
Date: 5 Oct 84 16:36:33 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Questions about OPEN
To: common-lisp@SU-AI.ARPA, heller%umass-cs.csnet@CSNET-RELAY.ARPA,
Moon@SCRC-RIVERSIDE.ARPA
In-Reply-To: Message from "Rob MacLachlan <RAM@CMU-CS-C.ARPA>" of 5 Oct 84 15:49:00 EDT
Maybe I didn't make it clear why I sent the message. I thought somebody
was suggesting that we should try to separate functions that take stream
arguments from those that take filenames (pathnames). In this case I
would expect that read and write would take streams, and rename and
delete would take filenames. If nobody proposed this, then my answer is
genuinely devoid of usefulness. I was arguing that it is useful to
continue to have rename-file and delete-file take either streams or
filenames. I assume I don't have to convince you that they should
take filenames. Sometimes we just want to rename a file, and if it
isn't open, we don't want to bother having to open it, rename it, and
close. The argument is (or at least I was imagining that it is) about
whether rename and delete should be legal on streams. I claim that
they should, for the very case that concerns you: I may not know the
name of the file that I want to rename. Thus it is useful to have an
operation that requests changing its name to something new, without
reference to any name that it may happen to have now. In case you don't
know the name of a file until you close it, you have at least two choices:
- close it, remember the name it got assigned (I trust you can find
out the name of a file when you close it?), rename it, and if
the semantics of rename-file are deemed to require this, reopen
it.
- if your O.S. lets you not specify the name until you close it,
don't do anything to the file -- just change the name you
are going to give it when it finally gets closed.
I certainly don't have any solution to the truename problem. I
understand that there is a genuine problem with that function on some
O.S.'s. I was trying to point out that allowing operations on open
streams can in some cases make the situation a bit better because we
don't ever need to know the old name of the file.
I have thought about your question as to when the JFN should be
released. I intended it to get released when you closed the stream. At
the moment rename-file implies a close in our implementation. This may
be a bug. (Would someone from the gang of 5 like to comment?) But that
is not relevant to this question. I was trying to preserve the ability
to do certain operations on a stream while it is still open, not say
they should never get closed.
By the way, a suggestion for doing truename on systems where you don't
know the name until close: If you have some way of making a file
invisible (e.g. by setting file protection so that no one can see it),
you could close it when it is initially opened, make it invisible, and
then open it for append access. This is roughly what Tops-20 does
internally. (Tops-20 has the same problem that this scheme would have:
if the system crashes while you are creating a file, you have this
partially-created file lying around which you may need to use unusual
methods to get rid of.)
-------
∂05-Oct-84 1555 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 15:53:05 PDT
Received: from hplabs by csnet-relay.csnet id cb17713; 5 Oct 84 18:15 EDT
Received: by HP-VENUS id AA19112; Thu, 4 Oct 84 15:15:47 pdt
Message-Id: <8410042215.AA19112@HP-VENUS>
Date: Thu 4 Oct 84 15:16:47-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: World peace
To: Fahlman%cmu-cs-c.arpa@csnet-relay.arpa,
quinquevirate%su-ai.arpa@csnet-relay.arpa,
ohlander%usc-isi.arpa@csnet-relay.arpa,
squires%usc-isi.arpa@csnet-relay.arpa,
fateman%ucb-vax.arpa@csnet-relay.arpa,
griss.hplabs%csnet-relay.arpa@csnet-relay.arpa,
shiel.pa%xerox.arpa@csnet-relay.arpa
Cc: fahlman%cmu-cs-c.arpa@csnet-relay.arpa, GRISS@hplabs.CSNET
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C>" of Wed 3 Oct 84 00:03:13-PDT
Source-Info: From (or Sender) name not authenticated.
I have carefully read Scott's and Steve's remarks. As you may know, I
have been involved with the use and implementation of LISP
"interchange subsets" and "portable subsets" for some time.
Standard LISP (1969, 1979) was an attempt to produce a simple
community concensus LISP for use in importing code onto a variety of
different machines and existing LISPs. Standard LISP was primarily
used to support research in the area of computer algebra (between
groups in the US, UK, Europe and Japan); it also saw use to permit the
porting of CAI code and experimental LISP-based languages. Some people
expanded the definition and made it the basis of new LISP
implementations (such as UT-LISP, some microcomputer LISPs, a portable
BCPL based Cambridge LISP, and PSL, my own portable LISP). A number of
portable tools evolved (Portable compiler, etc) that have been
exchanged by the community.
While I agree with Scott that it is not totally impossible to convert
finished programs from one dialect to the other, we have found it
intolerable to exchange code under development between dialects. (In
the algebra community, we have been exchanging major components of
frequently during their development over a number of years). Thus I
believe it is important to consider the need for an "interchange
subset" which is rich enough to do much of ones programming, or at
least of the parts that one wishes to exchange. Many of us feel that
Common LISP as it stands is rather large, and gaining community
consensus on a subset would be easier, as perhaps a step in the
transition to use of "full" Common LISP.
As part of my work at HP (dealing with networks of dissimilar
machines, different development and execution environments, layered
implementations of LISPs, etc..), and because of my own interests in
"world peace" I have been exploring a "new subset" with the Standard
LISP and PSL communities. The goal is to see what concensus I can
obtain for a successor to Standard LISP (and PSL) that is a
significant subset of Common LISP. If the results seem reasonable, I
will share the revised proposal and comments with the CL-subset
working group, for possible broadening (narrowing?) and revision to
include a wider community. At least my efforts will perhaps "bring in"
a segment of the non-Common LISP community.
At HP and some universities, we are running a variant of PSL that has
significant CL compatibility, and are working on tools to aid in the
transition from PSL to (a subset of) Common LISP. As these tools and
the subset definition matures, with use and input from our SL/PSL
community, I will have a better idea, and a more concrete proposal, of
what subset will be accepatable.
Martin Griss
-------
∂05-Oct-84 1815 @SU-SCORE.ARPA:JonL.pa@Xerox.ARPA Re: Aside about encapsulations
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 18:15:09 PDT
Received: from Xerox.ARPA by SU-SCORE.ARPA with TCP; Fri 5 Oct 84 17:49:02-PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 84 17:49:35 PDT
Date: 5 Oct 84 17:49 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Aside about encapsulations
In-reply-to: Steven <Handerson@CMU-CS-C.ARPA>'s message of Fri, 5 Oct 84
13:35 EDT
To: Handerson@CMU-CS-C.ARPA
cc: JonL.pa@XEROX.ARPA, COMMON-LISP%SU-AI@SU-SCORE.ARPA,
HEDRICK@RUTGERS.ARPA, Moon@SCRC-RIVERSIDE.ARPA,
Rem%IMSSS@SU-SCORE.ARPA, Wholey@CMU-CS-C.ARPA
Sounds quite interesting; two questions:
1) does your encapsulation notion bear any resemblence to the one
described in the LispMachineMaunal?
2) what do *you* mean by traceing any setfable "location"? I can
imagine tracing being applicable to SETF instances; and there are the
"good old days" of memory address traps wherein one could invoke a
function whenever any access is made to a specific address. Finally, I
might mention that "active values" is at the core of LOOPS, and there is
a minimal syntax in LOOPS for specifying "auditing" (similar to
traceing) a particular variable, or a particular record slot. "Active
values" nest in a way reminiscent of the way that encapsulations work in
the Lisp Machine.
-- JonL --
∂05-Oct-84 2046 Moon@SCRC-QUABBIN.ARPA Re: Questions about OPEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 20:46:32 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 89058; Fri 5-Oct-84 23:46:04-EDT
Date: Fri, 5 Oct 84 23:46 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Re: Questions about OPEN
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>, common-lisp@SU-AI.ARPA
cc: heller%umass-cs.csnet@CSNET-RELAY.ARPA
In-Reply-To: The message of 5 Oct 84 16:36-EDT from Charles Hedrick <HEDRICK at RUTGERS>
Message-ID: <841005234616.8.MOON@EUPHRATES.SCRC.Symbolics>
Date: 5 Oct 84 16:36:33 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
....At the moment rename-file implies a close in our implementation. This may
be a bug. (Would someone from the gang of 5 like to comment?)
I don't think anything but the CLOSE function should close a stream. So
it's a bug.
By the way, a suggestion for doing truename on systems where you don't
know the name until close: If you have some way of making a file
invisible (e.g. by setting file protection so that no one can see it),
you could close it when it is initially opened, make it invisible, and
then open it for append access. This is roughly what Tops-20 does
internally. (Tops-20 has the same problem that this scheme would have:
if the system crashes while you are creating a file, you have this
partially-created file lying around which you may need to use unusual
methods to get rid of.)
I think it would be better to define the language to make as few assumptions
about the operating system as possible, rather than requiring some implementors
to go through contortions to make their file systems look like the file systems
of other implementors. Obviously this has to stop before you reach a point
where no one can write a portable program because the language says nothing
about the semantics of any file system operation! In the particular case
of TRUENAME on an output stream that created a new file, I think it would be
wisest to say that this operation "is an error" until the stream has been
closed. Any system that knows the name earlier than that can simply not
check for the "error", and can save the name in the stream at the time it
closes it, for later use by the TRUENAME function.
∂05-Oct-84 2136 Moon@SCRC-QUABBIN.ARPA Questions about OPEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 21:35:28 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 89060; Sat 6-Oct-84 00:05:08-EDT
Date: Sat, 6 Oct 84 00:05 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Subject: Questions about OPEN
To: Rob MacLachlan <RAM@CMU-CS-C.ARPA>, common-lisp@SU-AI.ARPA
cc: "Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
In-Reply-To: <RAM.12052930752.BABYL@CMU-CS-C.ARPA>
Message-ID: <841006000512.9.MOON@EUPHRATES.SCRC.Symbolics>
Date: Fri, 5 Oct 1984 02:46 EDT
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
I concede those points, and was aware that, for example,
Rename-File has somewhat different semantics on a stream than it has
on the name. I can deal with that, since all we have to do in Spice
Lisp to implement this is change the name we write the data out as
when we close the file. You clarification, however, seems to assume
that there is some concept of file identity independent of the file
name. This is not true in Sesame, and is probably not true in many
file systems. There is no way to keep track of a file across
renamings and other operations.
I guess we have several options here:
1] We can leave the manual the way it is, with the semantics of use
of streams vis a vis pathnames largely unspecified. This would permit
implementations to do arbitrarily whizzy things, but would make the
use of stream arguments difficult in portable code, and thus dubious
as a Common Lisp feature.
2] We can try to define the semantics. This course is fraught with
peril, since capabilities of operating systems differ wildly.
3] We can punt and remove them.
Is there really such a big issue here? All the functions in section
23.3 are allowed already to have implementation-dependent variations
(note at the head of the section). OPEN is allowed similar freedom
(note on page 421). All the other functions, other than TRUENAME, when
given a stream simply convert it into a pathname. In fact I can find
nothing in the manual that says how this is done! But I'm sure the
intention is that PATHNAME when applied to a stream simply returns the
argument that was given to OPEN to create that stream (coerced to a
pathname of course). So I think the only function with a real problem
is TRUENAME. I believe that the note at the front of section 23.3 ought
to be applied to TRUENAME as well, word for word.
In many cases, the CLM seems to do 1, on the grounds that it would
be nice to have a standard way to say X, given that X is possible. I
have mixed feelings about this. In the case of the
:If-Exists/:If-Does-Not-Exist arguments to Open, it seems reasonable,
since even an inconceivably brain-damaged OS should be able to provide
some sort of reasonable default action, and the program will still
work. In the case of Rename-File, though, the call will error out,
(or worse, simply quietly fail) if the capability to rename open files
doesn't exist. A program counting on this feature would not work, and
thus would not be portable.
I think that this business of streams-as-files is especially
problematical in our implementation, since there is no "file attached
to the stream", only a memory buffer area where you are building up a
file that you may write out when the stream is closed. Sesame is in
fact a system such as you mentioned, in which it is impossible to
determine the truename of an "open" file, since the version number is
determined when the file is written. It seems to me that this
argument could just as easily be used to support the position that the
feature should be flushed as being impossible to specify in a
implementation independent fashion.
For us, the Probe-File and Truename functions are the most
annoying. The Rename-File and Delete-File functions, which don't have
to work right according to the CLM, are easily implementable.
The CLM doesn't say this, but I would hope that these functions are guaranteed
either to do what the manual says or to signal an error, not to quietly ignore
the request or anything like that. This can be pernicious -- we just found a
bug of such nature this week. I believe that it is okay for a Common Lisp
implementation to signal an error for any file operation, saying "the underlying
file system our implementation is built on is incapable of implementing that
Common Lisp function, too bad". I no more believe that Common Lisp implementors
should be required to rewrite their host operating systems than I believe that
they should be required to redesign their host hardware. Of course this means
that some programs will be more portable than others, and some programs will
port to some implementations but not others. In practice that is always the
situation and there is nothing you can do about it. But I believe the note
at the front of section 23.3 ought to be changed to say that these functions
will either work or signal an error. None of them need "is an error" freedom
since they aren't operations whose efficiency matters.
Currently, our implementation does not obey the
(probe-file (open ...)) => t
invariant. We could dummy it up so that it would return the pathname
that it thinks it is going to write the file out to, but that would
cause anomalous behavior such as:
(probe-file stream) => <some pathname>
(probe-file <some-pathname>) => nil
I believe the statement under PROBE-FILE, "Note that if the file is an open
stream associated with a file, then probe-file cannot return NIL but will
produce the true name of the associated file" to be bogus. I think PROBE-FILE
should simply call PATHNAME to coerce its argument to a pathname, as the
functions in 23.1 and 23.2 do, rather than treating streams specially, as
the other functions in 23.3 do. I think your argument above is convincing
and my suggested change would make things more consistent.
∂05-Oct-84 2256 RAM@CMU-CS-C.ARPA Questions about OPEN
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 22:55:59 PDT
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 6 Oct 84 01:55:29-EDT
Date: Sat, 6 Oct 1984 01:55 EDT
Message-ID: <RAM.12053183664.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Cc: common-lisp@SU-AI.ARPA,
"Robert (LISPer 68K)Heller" <heller%umass-cs.csnet@CSNET-RELAY.ARPA>
Subject: Questions about OPEN
In-reply-to: Msg of 6 Oct 1984 00:05-EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
I think that I mostly agree with your suggestions, but there are
some areas of confusion:
What should the semantics of Truename be as compared to
Probe-File? My original interpretation was:
(defun truename (file)
(or (probe-file file)
(error "File ~S does not exist." file)))
You seem to want to assign subtly different semantics to the two.
Under your interpretation of Truename, what is the name returned
when the stream is open for output and the file already existed? Is it:
1] The preexisting file?
2] The new file?
3] Either one?
4] Something else?
5] Undefined?
As we have discussed at length, 2 is impossible in some OS'es. 1 is
probably always possible, but might not be considered the most natural
by everyone.
Rob
∂06-Oct-84 1350 RPG Mail to me
∂04-Oct-84 1226 Moon@SCRC-STONY-BROOK.ARPA Mail to me
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:26:12 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 103706; Thu 4-Oct-84 15:17:09-EDT
Date: Thu, 4 Oct 84 15:17 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Reply-To: moon%scrc@MIT-MC.ARPA
Subject: Mail to me
To: Fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA
Message-ID: <841004151727.4.MOON@EUPHRATES.SCRC.Symbolics>
No doubt you've noticed that you haven't been able to send any mail to
me for weeks. Last week one of the several pdp11s that obstructs my
access to the Arpanet was broken all week. It's up again currently (a
working pdp11 was cobbled together out of two broken ones). However,
for some long period of time, I think several weeks, some VAX at MIT
that also obstructs my Arpanet access has been broken. The current
state is that Chaosnet between MIT and Symbolics works, but Internet
between Symbolics and the outside world does not work. Our mailers have
been patched (today) to use multiple hops to get mail out, but you can't
get mail back to me unless you do the same thing. Sending mail to
moon%scrc@mit-mc should work to send mail to me.
I hope this will be fixed soon. It's ridiculous to try to participate
in Common Lisp discussions when I can't send mail. However, I can't
promise when this will be fixed. I don't even know where this kludgey
VAX is, and it belongs to MIT, not to Symbolics. The only real solution
will be for Symbolics to get its own connection to an IMP and I'm not
sure what the current status of Arpa's (DCA's) interest in that is.
∂06-Oct-84 1351 RPG Mail to me
∂04-Oct-84 1226 Moon@SCRC-STONY-BROOK.ARPA Mail to me
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:26:12 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 103706; Thu 4-Oct-84 15:17:09-EDT
Date: Thu, 4 Oct 84 15:17 EDT
From: "David A. Moon" <Moon@SCRC-RIVERSIDE.ARPA>
Reply-To: moon%scrc@MIT-MC.ARPA
Subject: Mail to me
To: Fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA
Message-ID: <841004151727.4.MOON@EUPHRATES.SCRC.Symbolics>
No doubt you've noticed that you haven't been able to send any mail to
me for weeks. Last week one of the several pdp11s that obstructs my
access to the Arpanet was broken all week. It's up again currently (a
working pdp11 was cobbled together out of two broken ones). However,
for some long period of time, I think several weeks, some VAX at MIT
that also obstructs my Arpanet access has been broken. The current
state is that Chaosnet between MIT and Symbolics works, but Internet
between Symbolics and the outside world does not work. Our mailers have
been patched (today) to use multiple hops to get mail out, but you can't
get mail back to me unless you do the same thing. Sending mail to
moon%scrc@mit-mc should work to send mail to me.
I hope this will be fixed soon. It's ridiculous to try to participate
in Common Lisp discussions when I can't send mail. However, I can't
promise when this will be fixed. I don't even know where this kludgey
VAX is, and it belongs to MIT, not to Symbolics. The only real solution
will be for Symbolics to get its own connection to an IMP and I'm not
sure what the current status of Arpa's (DCA's) interest in that is.
∂06-Oct-84 1401 RPG Working Groups
∂04-Oct-84 1229 Moon@SCRC-STONY-BROOK.ARPA Working Groups
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Oct 84 12:29:33 PDT
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 103714; Thu 4-Oct-84 15:24:38-EDT
Redistributed-date: Thu, 4 Oct 84 15:24 EDT
Redistributed-to: RPG@SU-AI.ARPA
Redistributed-date: Sun, 30 Sep 84 22:15 EDT
Redistributed-to: RPG@SU-AI.ARPA
Date: Tue, 25 Sep 84 19:44 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Subject: Working Groups
To: RPG@SU-AI.ARPA
In-Reply-To: The message of 23 Sep 84 19:47-EDT from RPG at SU-AI
Message-ID: <840925194455.8.MOON@EUPHRATES.SCRC.Symbolics>
Date: 23 Sep 84 1647 PDT
From: Dick Gabriel <RPG@SU-AI.ARPA>
At the Monterey Common Lisp Meeting a number of working groups were
established....If you have already received an `Introduction' letter for one of these subgroups,
then you are already in that subgroup. If you did not and believe you ought to
be, please send mail to RPG@SAIL.
So far I have received no messages other than this one. I guess it's possible that
some messages are queued in a mailer somewhere. I signed up for 2 or 3 working groups.
Well, it turned out that one of the pdp-11s that obstructs my access to the Arpanet
was down. It's been down for about a week, but it's fixed now. If it stays fixed,
perhaps you could resend me any mail that got returned to you as undeliverable.
Well, it also turned out that various other network related things are fucked up.
I sent you another message about this a few minutes ago. If convenient, could you
send anything I should know about that has bounced back to you to MOON%SCRC@MIT-MC?
Mail
I've changed your address (and weinreb's) to "<hacker>%scrc"@MC, which is the
syntax we use to go the route you suggest. I'm sending this out to test it.
-rpg-
∂06-Oct-84 1523 RPG Communication difficulties
∂05-Oct-84 1035 DLW@SCRC-STONY-BROOK.ARPA Communication difficulties
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Oct 84 10:34:52 PDT
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 104303; Fri 5-Oct-84 13:35:18-EDT
Date: Fri, 5 Oct 84 13:35 EDT
From: "Daniel L. Weinreb" <DLW@SCRC-RIVERSIDE.ARPA>
Subject: Communication difficulties
To: rpg%sail@MIT-MC.ARPA
Message-ID: <841005133534.3.DLW@CHICOPEE.SCRC.Symbolics>
I have been receiving COMMON-LISP mail, but I have not gotten anything
from the new sublists. I belive that the problem would be solved if my
address were given as DLW at MIT-MC instead of directly to Symbolics,
because our Internet gateway to MIT seems to be totally unreliable.
Could you check the lists and see how I am being referenced? RSVP via
MC so I'll know that you got this... Thanks. -- Dan
Did you get my message mailed to you and Moon today. It was to:
"DLW%SCRC"@MIT-MC
-rpg-
∂06-Oct-84 1931 SQUIRES@USC-ISI.ARPA Re: World peace
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 6 Oct 84 19:31:15 PDT
Date: 6 Oct 1984 22:30-EDT
Sender: SQUIRES@USC-ISI.ARPA
Subject: Re: World peace
From: Stephen L. Squires <SQUIRES@USC-ISI.ARPA>
To: Fahlman@CMU-CS-C.ARPA
Cc: SQUIRES@USC-ISI.ARPA, fateman@UCB-VAX.ARPA
Cc: griss.hplabs@CSNET-RELAY.ARPA, kahn@USC-ISI.ARPA
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA
Cc: sheil.pa@XEROX.ARPA
Message-ID: <[USC-ISI.ARPA] 6-Oct-84 22:30:34.SQUIRES>
In-Reply-To: <FAHLMAN.12052892645.BABYL@CMU-CS-C.ARPA>
To avoid starting another series of rumors, I think that it is
important to clarify what I believe we agree on since my
understanding is based upon a series of messages.
To "first order": DARPA should not "prematurely" standardize on
Common LISP, that DARPA should standardize on Common LISP for the
appropriate community of interest first (delivery of SC
products), and that standarization in other communities will
develop as development enviroments and advanced environment
components mature in Common LISP, and that DARPA should listen
carefully to the community with particular attention to those
actually producing LISP products and using those products so that
the transtition is managed effectively.
However, we have not yet discussed the specifics of the rate of
change that is needed and that can be tolerated.
I believe that we are at a critical point in the transition
process because of the potential to have the next generation of
LISP products including high performance machines using Common
LISP. DARPA needs to take a clearly defined strong position
which will encourage the next generation to support Common LISP
and to encourage the transition of the existing generation to
Common LISP while working hard to work with those using other
LISPs to facilitate the transtion. The notion of a Common LISP
subset with some additional systems support with perhaps a
strengthening of the package facility to allow integrating
packages using different extended Common LISPs may help this
process.
The time period for transition in the Strategic Computing product
community needs to be about two or three years. If it is any
longer then it may be too late to satisfy the needs of Strategic
Computing. This would mean that the products could be developed
in any effective development environment providing that the
product is in Common LISP (perhaps a subset) and that the
enviroment can be used to further develop (maintain) a product in
Common LISP (subset). It would take another few years for well
engineered development enviroments to emerge that are completely
in Common LISP.
I agree that it would be to discuss possible policy issues.
Since DARPA needs a solution to the multiple LISP problem it is
going to have to make some decision after listenting to all the
issues.
∂08-Oct-84 0908 RPG Re: Varia
∂06-Oct-84 1815 JonL.pa@Xerox.ARPA Re: Varia
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 6 Oct 84 18:15:18 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 84 18:14:32 PDT
Date: 6 Oct 84 18:14 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Varia
In-reply-to: Dick Gabriel <RPG@SU-AI.ARPA>'s message of 06 Oct 84 15:22
PDT
To: RPG@SU-AI.ARPA
cc: jonl.pa@XEROX.ARPA
Hmmm, I too re-searched the recent AIList summaries, and didn't see the
"notice" there. Foo, it's somewhere in the bowels of my mail files (I
hope it didn't get deleted) -- hard to imagine what other list I'm
currently on that would carry such news (about Tartan preparing to offer
a Common Lisp product). It came some time after the following report
(which is unlikely to be "news" to you):
----------------------------------------------------------------
Date: 21 Sep 84 18:09 PDT
From: DMRussell.pa
Subject: Rumors from DEC
To: Sheil, JONL, Masinter, DeKleer
cc: DMRussell.pa
I spoke with my inside contact (works on the CommonLisp development team
in Hudson) --
* The VAX-on-a-chip is working in prototype. VMS runs pretty well on
the version they have now. They expect to have working versions in the
DEC labs within a year. Delivery vehicle will probably be priced about
$20K (!), come with 4 meg of main memory (I'm surprised!), and use a
68000 graphics coprocessor to reduce the load on the VAXChip.
* They don't know any more about TI's machine than we do.
* Their CommonLisp development team is now at 7 people, they will grow
to 15 or so by end of '85.
--- DMR ---
----------------------------------------------------------------
Wednesday or Thursday evening for a dinner with "the boys" sounds fine
-- just let me know which.
-- JonL --
∂08-Oct-84 1033 cpd@UCLA-LOCUS.ARPA How so I get on this List?
Received: from UCLA-LOCUS.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 10:33:22 PDT
Date: Mon, 8 Oct 84 10:23:36 PDT
From: Charles Dolan <cpd@UCLA-LOCUS.ARPA>
To: common-lisp@su-ai
Subject: How so I get on this List?
Is this how? If not please send me more information.
-Charlie Dolan
cpd@UCLA-LOCUS.ARPA
∂08-Oct-84 1045 cpd@UCLA-LOCUS.ARPA Benchmark - PERQ CL vs Apollo T
Received: from UCLA-LOCUS.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 10:45:12 PDT
Date: Mon, 8 Oct 84 10:17:49 PDT
From: Charles Dolan <cpd@UCLA-LOCUS.ARPA>
To: T-Users@Yale, Lisp-Forum@MIT-MC, Common-Lisp@Su-AI
Subject: Benchmark - PERQ CL vs Apollo T
UCLA has a demo unit of the new PERQ 68000 based workstation
running Common Lisp. We are currently using Apollo workstations
and T. I compared the workstations on the following points:
standard shell startup,
standard editor startup,
lisp editor startup,
compilation,
(fact 100) - recursive factorial,
(tak 18 12 6) - code given below,
(reverse1 *long-list*) - recursive reverse of a 100
element list, and
(reverse2 *long-list*) - recursive reverse of a 100
element list using closures.
The DN300 is Apollo's low end workstation. It had 1.5 MB and no
local disk. The DN460 is Apollo's bit-slice implementation of the
68000 instruciton set.
PERQ DN300 DN460
shell 10 sec 2/5.5 sec [5] 1/3 sec [5]
editor 7 sec 1 sec 1 sec
lisp editor [1] 14/1.5 sec 23.3/3 sec 10.5/1.8 sec
compilation [4] 11 sec 54 sec 24 sec
(fact 100) 2.1 sec 1.12 sec 0.61 sec
(tak ...) [3] 6.3 sec 3.4/6.3 sec [2] 1/2.7 sec [2]
(reverse1 ...) 2.2 sec 1.2 sec 0.42 sec
(reverse2 ...) 2.7 sec 1.6 sec 0.67 sec
All times were computed by running the funciton is a loop 30
times and dividing the wall clock time by 30.
[1] Since the lisp editors are embedded in the lisp environment
two times are given. The first is for the initial startup of
the editor the first time it is invoked. The second is for
subsequent invocations.
[2] The faster of the two times times is for the case when block
complilation is used. Here the recursive calls to (tak ...)
are compiled as jumps.
[3] In the T code explicit calls to the FIXNUM arithmetic
routines 'FX<' and 'FX-' were used.
[4] The which was compiled is the code below plus one auxiliary
function for each benchmark which performed the loop.
[5] The first time is for the AEGIS shell. The Second is for the
AUX cshell.
The code follows.
T:
(define (fact i) (cond ((eq? i 0) 1)
(T (* i (fact (-1+ i))))))
Common Lisp:
(defun fact (i) (cond ((eq i 0) 1)
(T (* i (fact (1- i))))))
T:
(define (tak x y z)
(cond ((not (fx< y x)) z)
(T
(tak (tak (fx- x 1) y z)
(tak (fx- y 1) z x)
(tak (fx- z 1) x y)))))
Common Lisp:
(defun tak (x y z)
(declare (type integer x)
(type integer y)
(type integer z))
(cond ((not (< y x) z)
(T
(tak (tak (- x 1) y z)
(tak (- y 1) z x)
(tak (- z 1) x y)))))
T:
(define (reverse1 l)
(cond ((null? l) nil)
(T (append (reverse1 (cdr l)) (list (car l))))))
Common Lisp:
(defun reverse1 (l)
(cond ((null l) nil)
(T (append (reverse1 (cdr l )) (list (car l)))))
T:
(define (reverse2 l)
(cond ((null? l) (lambda () l))
(T (lambda () (append (apply (reverse2 (cdr l)) ())
(list (car l)))))))
Common Lisp:
(defun reverse2 (l)
(cond ((null l) (function (lambda () l)))
(T (function
(lamda () (append (apply (reverse2 (cdr l)) ())
(list (car l))))))))
-Charlie Dolan
cpd@UCLA-LOCUS.ARPA
∂08-Oct-84 1255 WHOLEY@CMU-CS-C.ARPA Benchmark - PERQ CL vs Apollo T
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 12:52:52 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 8 Oct 84 15:51:34-EDT
Date: Mon, 8 Oct 1984 15:51 EDT
Message-ID: <WHOLEY.12053860153.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Charles Dolan <cpd@UCLA-LOCUS.ARPA>
Cc: Common-Lisp@SU-AI.ARPA, Lisp-Forum@MIT-MC.ARPA, T-Users@YALE.ARPA
Subject: Benchmark - PERQ CL vs Apollo T
In-reply-to: Msg of 8 Oct 1984 13:17-EDT from Charles Dolan <cpd at UCLA-LOCUS.ARPA>
Date: Monday, 8 October 1984 13:17-EDT
From: Charles Dolan <cpd at UCLA-LOCUS.ARPA>
UCLA has a demo unit of the new PERQ 68000 based workstation
running Common Lisp.
The PERQ is not a 68000 based machine. There's a bit-sliced processor inside
of it. It's basically a 16-bit machine.
PERQ DN300 DN460
(tak ...) [3] 6.3 sec 3.4/6.3 sec [2] 1/2.7 sec [2]
Tak runs in under 5 seconds on my Perq. The Perq Common Lisp implementation
has been undergoing extensive tuning during the past few months, and I bet
you've got a somewhat old version.
The current situation is that people at CMU are still doing most of the
development work, while the Lisp people at Perq systems are doing things like
getting better interfaces to the operating system servers up.
Over the past two weeks I've added register instructions to the Lisp
instruction set (full runtime type-checking, by the way). Some benchmarky
things have improved dramatically, for example,
(dotimes (i 1000000)) ; That's one million
took over 20 seconds before the addition of registers, and now takes 5.5
seconds. I bet the register instructions will help some of your other
benchmarks as well.
"Benchmarking is, at best, a black art." I'd like to see some large bechmarks
run on a large number of machines (something like OPS5). I like things along
the lines of compilation speed and how fast the editor reads and writes files.
Those are things that most people do a lot, and spend time waiting for.
Common Lisp and T are very different languages, and I bet I could devise some
benchmarks that ran significantly faster on the Perq than on the Apollo
machines. Have you tried CTAK (TAK using catch and throw)?
I don't want to thwart your benchmarking effort, and I'm not offended or
anything, but I felt I should mention that the Perq Lisp system is still in the
tuning phase.
--Skef
∂08-Oct-84 1942 KMP@MIT-MC Questions about OPEN
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 19:42:25 PDT
Date: 8 October 1984 22:42-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Questions about OPEN
To: Common-Lisp @ SU-AI
cc: RAM @ CMU-CS-C, heller%umass-cs.csnet @ CSNET-RELAY,
Moon @ SCRC-RIVERSIDE
In-reply-to: Msg of Sat 6 Oct 84 00:05 EDT from David A. Moon <Moon at SCRC-RIVERSIDE.ARPA>
Everyone has spoken about what they think the published word says will
happen, but no one has really said anything about what users might in
fact need.
If I'm writing code that works on an open file and wants to know
the truename, it is generally so I can either record information
somewhere (eg, type "Script file PS:<JDOE>FOO.TEXT.7 opened." on the
console) or so I can use the information in some formal operation
(such as producing a new pathname from the truename to put next to
it in a directory). If I care about matching version numbers for some
reason (eg, I want "FOO.OUTPUT.7" to accompany "FOO.INPUT.7"), then
it may then be important to me that I get back #<Path "FOO.TEXT.7">
from truename and not #<Path "FOO.TEXT.newest"> and it's a pain to
have to write the code that probes FOO.TEXT for numberness (or zeroness,
in the case of Twenex, or...).
I agree with Moon that functions that can't fulfill their contract due
to OS limitations should err, but I know that I have always been willing
to use heuristic information in this particular area and I think that
in some cases relaxing the definitions a little could work pretty well.
Eg, TRUENAME might return two values, a pathname and a boolean saying
whether that pathname was really the truename or just a good guess.
This, I think, would provide the user with all the information that either
kind of operating system could provide without being too obtrusive.
If someone thinks this would occasionally do the wrong thing, it could
be safeguarded by taking an optional arg ERROR-P, default T, which if
true would signal an error before returning a second value of NIL, so
the person would have to do (TRUENAME obj NIL) to get back two values.
I would tend to oppose solutions to these issues which will hide useful
information for the sake of generality, preferring to support solutions
which present all the known data to the user in a flexible way and leave
him to decide about how to handle the problem.
By the way, I believe that the decision to have TRUENAME err rather than
return multiple values is partly influenced by the fact that the LispM
now has a sophisticated condition-handling system which can make use
of complicated information conveyed in error objects. Since Common-Lisp
error handling primitives are not so sophisticated -- good grief, I just
checked the manual and there's not even an ERRSET primitive; let me ammend
that -- since Common-Lisp error handling primitives are quite literally
non-existent, there is no way a user can even do:
(OR (IGNORE-ERRORS (TRUENAME ...)) (PATHNAME ...))
right now if he expects a problem. But certainly if we expect this to be
a common case, allowing something like the above-proposed
(TRUENAME ... NIL) would be more concise and informative.
-kmp
∂08-Oct-84 2104 KMP@MIT-MC Maclisp interpreter/compiler nearly identical w/ (declare (special t)) on??
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 8 Oct 84 21:03:34 PDT
Date: 9 October 1984 00:02-EDT
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Maclisp interpreter/compiler nearly identical w/ (declare (special t)) on??
To: fateman @ UCBDALI
cc: common-lisp @ SU-AI
In-reply-to: Msg of Fri 14 Sep 84 09:40:12 pdt from fateman%ucbdali at Berkeley (Richard Fateman)
Date: Fri, 14 Sep 84 09:40:12 pdt
From: fateman%ucbdali at Berkeley (Richard Fateman)
... If we look at Maclisp with (declare (special t)), is it not the
case that (nearly) identical semantics are used for the interpreter
and compiler, given CORRECT programs? ...
I'm afraid I take offense at this. Maclisp interpreted semantics are *very*
different than compiled semantics. Common Lisp is not completely there, but
puts its heart in the right place by at least acknowledging the problem.
Also, it has corrected at least some of the Maclisp problems. Here are a
few Maclisp interpreter/compiler differences that come to mind at the
moment to jar your memory; I'm sure this is not an exhaustive list:
* If you make a "correct" number declaration for X and Y, you may
risk that (PLUS X Y) which would run correctly interpreted will
be open coded as if (+ X Y) had been written. In PLUS case interpreted,
however, overflow becomes a bignum while in the + case interpreted,
the result is undefined (wraparound or some such thing occurs undetected).
I didn't see any obvious place in the CL manual where it says if
this is fixed.
* There are a bunch of control variables such as CAR, CDR, and EVAL
which are (necessarily) ignored by compiled code. They radically
affect the semantics of interpreted code by allowing the user to
extend the notion of what was "defined" without providing a mechanism
for informing the compiler of such extensions.
There are no such variables in CL.
* The status of macros in the car of a form was not uniformly treated in
interpreted and compiled form. In the form ((FOO BAR) ...), if FOO was a
macro, the interpreter would cause the result of expanding (FOO BAR) to be
evaluated before being applied, while the compiler would compile an apply
to the result of expanding (FOO BAR) directly rather than compiling a call
to the result of evaluating the expansion. Early Maclisp actually attempted
to define this as reasonable behavior; I think it was eventually flushed
and compiler warnings were issued in some cases saying to use FUNCALL.
I could not determine where or whether the CL manual takes a stand on this
issue. It would be nice if it simply declared that forms other than
((LAMBDA ...) ...) whose cars are lists are explicitly undefined.
* Compiled macros, if redefined, have no effect on running programs.
This is still true in CL. If interpreted CL definitions were ENCLOSE'd
(a la Scheme) at definition time, this could be fixed.
* Constant quoted expressions which were EQUAL will have been made EQ by the
FASLOAD process. This fact has been heavily depended upon by Macsyma on
the pdp10 to avoid wasting huge amounts of space needlessly, and must be
understood by all programs to avoid accidentally side-effecting constants
which ought by right have no relation to each other.
I guess this one is under active discussion.
* Function definitions for interpreted and compiled code differ.
(FUNCALL (GET 'X 'EXPR)) runs the same interpreted and compiled, but
(DEFPROP X (LAMBDA () 3) EXPR) runs differently compiled than interpreted.
There is definitely an advance in CL by having simply a function cell and
eliminating this nonsense about having 18 different places to store
functions. There's some question in my mind about whether macros belong
in the function cell, but this is at least treated uniformly from
interpreter to compiler.
* EVAL-WHEN does different things in an EVAL context than a COMPILE context.
I can't imagine wanting to fix this given the current state of the world,
although if, as I mentioned above, CL had an analog to Scheme ENCLOSE which
was used at appropriate times in both interpreter and compiler, I could
imagine changing the set of keys that EVAL-WHEN used (to not be EVAL and
COMPILE, but instead something more abstract) so that they were uniformly
treated in interpreted and compiled code.
* EVALFRAME works completely differently in compiled and interpreted contexts
since call the compiler may optimize out intermediate call frames. Hence
(LET ((THIS-FRAME (EVALFRAME ...))) ...) works fine compiled but must be
treated very carefully interpreted.
This issue isn't addressed by CL, hence is sort of fixed.
* Number EQness of small numbers may not be preserved in compiled code, but
is guaranteed in many cases in interpreted code. Technically, it was never
guaranteed that this was so, but in practice, I (and probably others) wrote
code that relied on the fact and achieved useful ends.
The introduction of EQL in CL makes a positive stride in the right direction.
I don't know if I consider this problem completely resolved.
∂09-Oct-84 1230 PERDUE%hp-hulk.csnet@csnet-relay.arpa Re: Questions about specification and possible implementations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Oct 84 12:30:12 PDT
Received: from hplabs by csnet-relay.csnet id ac10239; 9 Oct 84 15:12 EDT
Received: by HP-VENUS id AA11495; Mon, 8 Oct 84 17:46:25 pdt
Message-Id: <8410090046.AA11495@HP-VENUS>
Date: 8 Oct 1984 1747-PDT
From: PERDUE%hplabs.csnet@csnet-relay.arpa
Subject: Re: Questions about specification and possible implementations
To: Common-lisp%su-ai.arpa@csnet-relay.arpa
In-Reply-To: Your message of 4-Oct-84
Source-Info: From (or Sender) name not authenticated.
I consider Skef Wholey to be incorrect when he says that "it is
an error" to redefine BUILT-IN keyword functions. In the
published Common LISP manual on page 90 under the heading
"symbol-function" I see:
The global function definitiion of a symbol may be altered by
using setf with symbol-function. . . . It is an error to
attempt to redefine the name of a special form (see Table 5-1).
Does anyone else know differently from this?
-------
∂09-Oct-84 1422 WHOLEY%cmu-cs-c.arpa@csnet-relay.arpa Questions about specification and possible implementations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 9 Oct 84 14:21:23 PDT
Received: from cmu-cs-c.arpa by csnet-relay.arpa id a010978; 9 Oct 84 17:14 EDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 9 Oct 84 17:11:19-EDT
Date: Tue, 9 Oct 1984 17:11 EDT
Message-ID: <WHOLEY.12054136820.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY%cmu-cs-c.arpa@csnet-relay.arpa
From: Skef Wholey <Wholey%cmu-cs-c.arpa@csnet-relay.arpa>
To: PERDUE%hplabs.csnet%csnet-relay.arpa@csnet-relay.arpa
Cc: Common-lisp%su-ai.arpa%csnet-relay.arpa@csnet-relay.arpa
Subject: Questions about specification and possible implementations
In-reply-to: Msg of 8 Oct 1984 20:47-EDT from PERDUE%hplabs.csnet at csnet-relay.arpa
Ok, I retract that terminology. My point was that it's just as correct to
compile a keyword-taking function in a funny way as it is to open code CAR. If
a compiler is allowed to do the latter, it can certainly do the former.
JonL points out that this weakens the debugability of compiled code, since some
poor guy out there might want to trace CAR (or some other specially compiled
function) to find out what's going on. There are a few solutions to this
problem:
1. He can debug his code in the interpreter -- a problem if he's
already loaded a lot of compiled code. But anything calling itself a
Lisp environment should give the user a way to easily load the
interpreted definition of a few functions. This could be done in the
editor, or perhaps grabbing the interpreted definition if the compiler
had the foresight to save it someplace for him.
2. He can (PROCLAIM (NOTINLINE CAR)) and recompile the functions he's
interested in. If he doesn't suspect that a function is being compiled
in some funny way, he should be able to find out using DISASSEMBLE in
the worst case.
3. Common Lisp could provide a declaration or somesuch that would cause
the compiler to perform no special compilation of functions. When
debugging, one could still get something like compiled speed while
retaining full tracability. This would presumably be easier than
declaring everything you might want to trace NOTINLINE .
Making option 1 feasible in practice requires a good environment (read not
batch) -- not something part of the Common Lisp specification. Still, it isn't
that hard for an implementor to provide such tools. Option 3 requires a change
to the language specification, but is probably even easier to implement that
Option 1. Option 2 is the worst-case, current language spec option.
Anyone for (PROCLAIM '(ENABLE-INLINE T)) and (PROCLAIM '(ENABLE-INLINE NIL))?
With better names and syntax maybe?
Shades of (SSTATUS FOO T)... Gasp.
--Skef
∂10-Oct-84 0907 jrg@cmu-cs-spice.arpa UCLA Perq
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 10 Oct 84 09:07:31 PDT
Date: Wednesday, 10 October 1984 11:58:31 EDT
From: Joseph.Ginder@cmu-cs-spice.arpa
To: wholey@cmu-cs-c.arpa
cc: T-Users@yale.arpa, Lisp-Forum@mit-mc.arpa, Common-Lisp@su-ai.arpa
Subject: UCLA Perq
Message-ID: <1984.10.10.15.38.13.Joseph.Ginder@cmu-cs-spice.arpa>
The Perq at UCLA, which I have seen in person, is running the Beta release
of S5 with the "slasher 1" version of lisp -- that is, a pre-release, not
even Beta. Thus, it does not have any of the new interfaces. I believe
that it is using Ucode from before the fast funcall stuff and caching was
put in, but don't recall for sure. That is, the ucode is probably 2 major
revisions old; and at least 1 major revision old. Also, no one has a Perq
lisp yet with the faster startup granted by using only the new interfaces.
(Every version of Perq lisp that I know of still uses the old ones at least
internally -- thus they must be initialized as before -- in addition to the
new, fast initializing versions.)
--Joe
P.S. No Perq has a 68000 in it. Or a 68010. All have board-level,
micro-programmable CPU's that aren't true bit-slices (like AMD2901's) but
have been described as such since the chip used for the ALU is 4-bits wide
and five are used to construct a 20-bit ALU. (No, I don't remember which
chip, but it's not a secret. It's some TI ALU chip.) And though the
current board has a 20-bit wide ALU, external data paths are 16 bits wide.
∂11-Oct-84 1824 JonL.pa%xerox.arpa@csnet-relay.arpa Re: Questions about specification and possible implementations
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 18:23:53 PDT
Received: from xerox.arpa by csnet-relay.arpa id a006036; 11 Oct 84 20:56 EDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 OCT 84 17:54:37 PDT
Date: 11 Oct 84 17:54 PDT
From: JonL.pa%xerox.arpa@csnet-relay.arpa
Subject: Re: Questions about specification and possible implementations
In-reply-to: Skef Wholey <Wholey%cmu-cs-c.arpa@CSNET-RELAY.ARPA>'s
message of Tue, 9 Oct 84 17:11 EDT
To: Wholey%cmu-cs-c.arpa%csnet-relay.arpa@csnet-relay.arpa
cc: PERDUE%hplabs.csnet%csnet-relay.arpa%csnet-relay.arpa@csnet-relay.arpa,
Common-lisp%su-ai.arpa%csnet-relay.arpa%csnet-relay.arpa@csnet-relay.arpa
Skef, I see a more serious problem with TRACE than can be encompassed by
your proposals.
Basically, it's still the same question raised by Hedrick initially --
when is it permissible for the compiler to *rename* functions out from
underneath you. The "you" in the preceeding sentence is not merely the
small module of functions that some programmer happens to be working on
at a given point in time. If he so foolishly wants to trace CAR (or
keyword function, or whatever), *** he may just as likely want it traced
in the system functions which use it, or in the funcitons from an
independently supplied module.
I'm not fond of constraining every function in the book -- CAR, CDR and
SVREF come to mind as outrageous to be so constrained. But I do "buy"
Hedricks argument about keyword-admitting and other such functions
[e.g., it would not be legit to rename LDB into SI:**LOAD-BYTE simply in
order to avoid the creation of a byte pointer].
-- JonL --
∂11-Oct-84 1951 WHOLEY@CMU-CS-C.ARPA Questions about specification and possible implementations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 19:50:57 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Thu 11 Oct 84 22:47:57-EDT
Date: Thu, 11 Oct 1984 22:47 EDT
Message-ID: <WHOLEY.12054722396.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: JonL.pa%Xerox@CMU-CS-C.ARPA
Cc: Common-Lisp@SU-AI.ARPA, PERDUE%hplabs.csnet%Csnet-Relay@CMU-CS-C.ARPA
Subject: Questions about specification and possible implementations
In-reply-to: Msg of 11 Oct 1984 20:54-EDT from JonL.pa%xerox.arpa at csnet-relay.arpa
You say that it's OK to open code some functions, like CAR and SVREF.
You say that it's not OK to do something like code a call to Write-Line with
:start and :end arguments as a call to some internal Keywordless-Write-Line to
avoid consing a rest argument.
Is it OK to open-code a function some times (e.g. when we know that the
sequence argument to Position is a simple-string and we know that the item
being searched for is a string-char, we could use the Vax SCANC instruction),
but not others? Is that "too complicated a function"? Realize that no one is
going to use those generic sequence functions if they always cons rest args and
parse keywords at runtime. I consider it an implementor's duty to try to
eliminate at least some of that runtime penalty.
What about "fast function calls?" Is it alright for an implementor to compile
his Lisp-level code in such a way that when system code calls Print the call is
untracable? Is it alright for the writer of a "module" to do so? Why should
the random user who wants to trace Print have any reason to believe that the
writer of the code supplied to him used that function? Sounds like
information-hiding to me. Last I checked, that was suppsoed to be a good
thing.
The only difference here seems to be what you might consider reasonable
things to open-code based on your knowledge about implementing Lisp. That's
going to vary a whole lot from machine to machine.
Partition the set of Common Lisp functions into three classes:
1. Those that may be open-coded.
2. Those that may either be open-coded or left alone.
3. Those that should never be open-coded.
Can you? Should you? Were you the one complaining about Common Lisp
discriminating against stock hardware? The sorts of optimizations I want to do
(and as a user, want done for me) can only help the performance on stock
hardware. If it were ruled that it was absolutely not permissable to cleverly
code any keyword-taking functions, "we" microcoded-machine people would just go
off and write some fast keyword-parsing microcode. What would the Vax and 20
people be left doing?
Remember that as a last resort, good old DISASSEMBLE is there. There IS a way
for the user to peer into compiled code to see what's really happening.
Information-hiding is a good thing, but a better thing about Lisp is that it
has usually provided a way around it, so that people can get work done. I've
used the Lisp Machine Inspector to "unlock" a package to hack some symbols in
that package. I didn't need to read any documentation or source code.
There's no real reason to treat compiled code as a black box and TRACE as
the only tool for finding things out about the contents of that box. Contrary
to what Hedrick says, this IS Lisp.
--Skef
∂11-Oct-84 2008 FAHLMAN@CMU-CS-C.ARPA Questions about specification and possible implementations
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 20:07:56 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 11 Oct 84 23:04:56-EDT
Date: Thu, 11 Oct 1984 23:04 EDT
Message-ID: <FAHLMAN.12054725497.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: JonL.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Questions about specification and possible implementations
One of the reasons that TRACE is only semi-documented (you ought to have
it and you should call it TRACE if you do) is that it doesn't come up in
portable code. It's clear that you want TRACE to be as powerful as
possible -- if there are things the user might want to see that he can't
see, that makes debugging a bit harder. It's also clear that
implementations are going to vary in the degree to which they allow you
to trace calls from compiled code. Some implementations are going to
use all sorts of tricks to get full efficiency, and some of these may
interfere with tracing. I think that the right attitude is that
interpreted code definitely should be traceable and anything else you
get is gravy.
So it seems to me that each implementation should do the best it can on
this, and should document which things you can trace and which you
can't. Do we need to say anything more about this?
-- Scott
∂11-Oct-84 2010 JonL.pa@Xerox.ARPA Re: Questions about specification and possible implementations
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 20:10:16 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 OCT 84 20:10:36 PDT
Date: 11 Oct 84 20:01 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: Questions about specification and possible implementations
In-reply-to: Skef Wholey <Wholey@CMU-CS-C.ARPA>'s message of Thu, 11 Oct
84 22:47 EDT
To: Wholey@CMU-CS-C.ARPA
cc: KMP@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA,
PERDUE%hplabs.csnet@CSNET-RELAY.ARPA
I hope your questions are rhetorical, and not directed to me -- I
certainly don't want to take on the task of deciding how far to
standardize the solidarity between interpreted code and compiled code.
Pitman has had some interesting comments about variations at that level
in Pdp10 MacLisp -- care to comment KMP?
-- JonL --
∂11-Oct-84 2027 JonL.pa@Xerox.ARPA Re: A few more items on "Questions about specification and
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 20:26:56 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 11 OCT 84 20:26:55 PDT
Date: 11 Oct 84 20:19 PDT
From: JonL.pa@XEROX.ARPA
Subject: Re: A few more items on "Questions about specification and
possible implementations"
In-reply-to: Skef Wholey <Wholey@CMU-CS-C.ARPA>'s message of Thu, 11 Oct
84 22:47 EDT
To: Wholey@CMU-CS-C.ARPA
cc: KMP@MIT-MC.ARPA, Common-Lisp@SU-AI.ARPA,
PERDUE%hplabs.csnet@CSNET-RELAY.ARPA
Oh, I forgot about this one
". . . to avoid consing a rest argument"
At the time that &rest arguments got standardized into Common Lisp, the
VAX/NIL was implementing them as vectors instead of lists. *** Thus
there was no consing for &rest args *** and it's precisely the adoption
of a list versus a vector format that shafts a stock hardware
implementation (assuming stock hardware precludes cdr coding etc) to the
favor of the MIT Lisp Machine and it's descendents.
And
"we could use the Vax SCANC instruction"
While having a string-scanning opcode is "nice" for a machine, that
doesn't necessarily mean that a function call to a function utilizing
that opcode is a burdensome overhead. The "win" of a single opcode for
things like that is the low loop overhead (unless your implementation
simply cannot do any function call without incurring gross overhead). A
"CAR" opcode, however, exhibits no "loop overhead".
The goal of PDP10 MacLisp was "speed at all costs"; to some degree, the
goal of Interlisp has been "programming aids at all costs". I'll be the
first to admit that the perceived value of "speed at all costs" should
be diminished by 6 orders of magnitude compared to what it was 20 years
ago when the PDP10 architecture was being developed. While TRACE may
not be the standard for "programming aids at all costs", still it is
useful not to have the compiler so effectively "hide" one's programs
that others cannot gain a good model of them from the source code.
-- JonL --
∂11-Oct-84 2122 REM%IMSSS.#Pup@SU-SCORE.ARPA Fast or slow linkage re TRACE, what to put in specs?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 21:22:22 PDT
Received: from IMSSS by Score with Pup; Thu 11 Oct 84 21:21:23-PDT
Date: 11 Oct 1984 2123-PDT
From: Rem@IMSSS
Subject: Fast or slow linkage re TRACE, what to put in specs?
To: COMMON-LISP%SU-AI@SCORE
(From a longstanding LISP user: SU-1.6, UCI-LISP, MacLISP <my favorite>,
USLISP, PSL; but newcomer to Common LISP.
Regarding what can be traced and what can be open-coded or otherwise
modified so it can't be traced.)
Date: Thu, 11 Oct 1984 22:47 EDT
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Is it alright for the writer of a "module" to [use fast linkage
when a function in the module calls another in the same module]?
Why should the random user who wants to trace Print have any
reason to believe that the writer of the code supplied to him used
that function? Sounds like information-hiding to me. Last I
checked, that was suppsoed to be a good thing.
I agree. When the a particular function-call within to a module is not
a documented one (thus the user doesn't have any reason to expect a
particular kind of linkage nor even the function call at all), and
when using fast (untraceable) linkage makes the code run faster or
take up less space, and when full (traceable) linkage is no longer
needed for debugging because this module is fully tested and being
distributed to customers, it's completely reasonable (fair,
permissible) to compile that function-call using fast linkage. If
somebody later wants to debug that module (a previously undiscovered
bug crops up, or modifications are desired), the module can be
recompiled using slow linkage during the debugging period, and then
restored to fast linkage when it's back in production form. <Opinion>
Partition the set of Common Lisp functions into three classes:
1. Those that may be open-coded.
2. Those that may either be open-coded or left alone.
3. Those that should never be open-coded.
I agree providing you're referring only to calls from user code. Calls
within system code may be fast-coded as pre my previous paragraph.
The user should have reason to expect calls from that user's code to a
certain class of functions (documented in class 3 above) will always
be slow-coded (traceable) when called from the user's own code. The
user should also be provided a facility to selectively modify the
behaviour of the compiler when desired so that calls from the user's
newly-compiled code to certain other specifically named functions will
also be slow-coded.
Information-hiding is a good thing, but a better thing about Lisp
is that it has usually provided a way around it, so that people
can get work done. I've used the Lisp Machine Inspector to
"unlock" a package to hack some symbols in that package. I didn't
need to read any documentation or source code.
This is a good alternative to tracing when you don't have the source
for somebody else's module, or you don't have time or desire to
recompile it, or it works fine with slow linkage but there's a bug in
open coding, etc. It may be too soon in the state of the art to
specify every Common-LISP implementation should have an inspector, but
such facility should perhaps be described and encouraged in the manual.
There's no real reason to treat compiled code as a black box and
TRACE as the only tool for finding things out about the contents
of that box. Contrary to what Hedrick says, this IS Lisp.
But TRACE is a good first measure to handle 90% of the problems.
Beyond simple TRACE, a PAUSE-TRACE should be available which prints
the arguments like TRACE, but then asks if the user wants (after
seeing arguments) to go into a BREAK (read-eval-print) loop before
executing the called function; then after printing the result asks
again if the user wants to go into a BREAK before returning. I think
Common LISP ought to have TRACE with break-before and break-after more
than it should have half the random cruft currently in the specs. <Out
on a limb opinion>
Date: Thu, 11 Oct 1984 23:04 EDT
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Some implementations are going to use all sorts of tricks
to get full efficiency, and some of these may interfere with
tracing. I think that the right attitude is that interpreted code
definitely should be traceable and anything else you get is gravy.
I agree. Calls from or to interpreted code always should be traceable
(but I don't think anybody has an implementation where this is
violated except where an FEXPR or MACRO is being called and the trace
package can't handle it, so this isn't the disputed point). We need to
think about how much gravy, since it truly is useful to trace compiled
calls from code that is compiled either because it's too slow to debug
interpreted or we thought it worked and now we see it really doesn't.
It's a royal pain to have to retreat to interpreted code just because
we want to trace a call. Therefore we really need some "gravy". The
question is how much and how to document it.
So it seems to me that each implementation should do the best it
can on this, and should document which things you can trace and
which you can't. Do we need to say anything more about this?
Maybe. Do we make it total caveat emptor, with each implementation
required only to document what it has done, or do we put some
constraints on implementation to force a minimal amount of "gravy"
across all systems. Since debugging is the essence of LISP, and all
customers of barebones Common LISP will expect the ability to debug
software they write, I don't think total caveat emptor is the way to go.
-------
∂11-Oct-84 2142 REM%IMSSS.#Pup@SU-SCORE.ARPA Whether interpreted&compiled code should agree initially?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 11 Oct 84 21:42:31 PDT
Received: from IMSSS by Score with Pup; Thu 11 Oct 84 21:41:25-PDT
Date: 11 Oct 1984 2142-PDT
From: Rem@IMSSS
Subject: Whether interpreted&compiled code should agree initially?
To: COMMON-LISP%SU-AI@SCORE
Date: 11 Oct 84 20:01 PDT
From: JonL.pa@XEROX.ARPA
I certainly don't want to take on the task of deciding how far to
standardize the solidarity between interpreted code and compiled code.
This reminds me. The old approach was that some "programs" would run
differently interpreted from compiled, mostly due to interpreted
variables defaulting to special while compiled variables defaulting to
local, but such programs with undeclared free variables weren't
regarded as "correct" LISP programs even though they ran ok
interpreted. Software existed (for example FCHECK for USLISP and PSL)
to look for undeclared free variables and other problems, so the
programmer could repair the code to be "correct", so that it would run
the same interpreted and compiled (more likely so it would compile at
all). A program wasn't considered finished until FCHECK or whatever
failed to find any source errors.
Common LISP has taken a different tack. At great pain interpreted code
is made to act like compiled code, so that trouble is found during
interpreted test runs rather than later during FCHECKing or attempts
at compiling. Does anybody have strong reason why this method is
better? (I always thought the purpose of a LISP interpretor was to be
able to hack together something which while not correct did run enough
that I could debug the various parts of it independently rather than
have everything break if one declaration early in the file was
missing. Then after getting it to basically work you start tuning it
to run more efficiently, i.e. compiled at all, and maybe with some
variables used in tight loops declared as FIXNUMs or BOOLEAN or (ARRAY
<const> <const>) etc. Doesn't Common LISP sort of go against the
hacking philosophy?) Why not allow interpreted and compiled code to
have different semantics for initial versions of programs that aren't
yet correct, but provide software for checking the correctness of
programs so they can be made to run the same both ways??
-------
∂12-Oct-84 0928 GRISS%hp-hulk.csnet@csnet-relay.arpa Re: World peace
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 12 Oct 84 09:28:22 PDT
Received: from hplabs by csnet-relay.csnet id ab09422; 12 Oct 84 12:22 EDT
Received: by HP-VENUS id AA05351; Fri, 12 Oct 84 04:25:37 pdt
Message-Id: <8410121125.AA05351@HP-VENUS>
Date: Fri 12 Oct 84 04:26:35-PDT
From: Martin <GRISS%hplabs.csnet@csnet-relay.arpa>
Subject: Re: World peace
To: Fahlman%cmu-cs-c.arpa@csnet-relay.arpa,
quinquevirate%su-ai.arpa@csnet-relay.arpa,
ohlander%usc-isi.arpa@csnet-relay.arpa,
squires%usc-isi.arpa@csnet-relay.arpa,
fateman%ucb-vax.arpa@csnet-relay.arpa,
griss.hplabs%csnet-relay.arpa@csnet-relay.arpa,
shiel.pa%xerox.arpa@csnet-relay.arpa
Cc: fahlman%cmu-cs-c.arpa@csnet-relay.arpa, GRISS@hplabs.CSNET
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C>" of Wed 3 Oct 84 00:03:13-PDT
Source-Info: From (or Sender) name not authenticated.
Im curious, did my reponse to this group regarding "compromise"
subsets reach anyone? I've some trouble with our mailer, and the lack
of even a B... S.... or some such comment seems to indicate no
receipt. I can resend, if needed.
Martin Griss
-------
∂12-Oct-84 1106 FAHLMAN@CMU-CS-C.ARPA World peace
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Oct 84 11:06:16 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 12 Oct 84 14:05:59-EDT
Date: Fri, 12 Oct 1984 14:05 EDT
Message-ID: <FAHLMAN.12054889488.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Martin <GRISS%hplabs.csnet@CSNET-RELAY.ARPA>
Cc: fateman@UCB-VAX.ARPA, ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA,
sheil.pa@XEROX.ARPA, squires@USC-ISI.ARPA
Subject: World peace
In-reply-to: Msg of 12 Oct 1984 07:26-EDT from Martin <GRISS%hplabs.csnet at csnet-relay.arpa>
Martin,
Your message reached me, at least. I didn't reply for a couple of
reasons. First, RPG was about to meet with the Xerox folks and I didn't
want to say anything more until I heard what they thought about all
this. Second, the mail program I use garbles CSNET address so badly
that I can't just say "reply". This means I'm unlikely to respond just
to say I got your mail and found it interesting.
A bit of reaction, as long as I'm doing this:
The plan I proposed, in which DARPA would impose a standard language on
researchers only when necessary, and then would require only that the
final running product RUN IN Common Lisp still looks good to me. I see
no reason to require people to adhere to some particular subset. Each
uncommon Lisp can decide for itself (with whatever help we can provide)
how best to develop programs that ultimately have to be ported to Common
Lisp. Those of us lucky enough to have a real Common Lisp to play on
can use the whole language without restrictions.
I think that you are addressing a slightly different problem: a
situation in which, for whatever reason, people want to be able to write
code that runs both in Common Lisp and in one or more uncommon dialects.
I think that this will be hard to pull off while still keeping the
subset large enough to be easily usable. If you are willing to modify
the pre-existing Lisp a bit, that would make the task easier. I also
think that this is not a problem that will be critical for too many of
us -- most of us will either move over cleanly to Common Lisp or stay in
our old Lisp environments with the occasional need to export some code
to Common Lisp. But I am sure that SOME users will end up having to
straddle the fence and to write code that swings both ways, and for them
your subset, if you can pull it off, would be a real boon.
On the problem of developing an application in Common Lisp but making
the final product run on some smaller machine (a missile guidance system
or a laboratory instrument), I tend to favor an approach that prunes
away any part of the Common Lisp runtime system that is not being used
by a particular application, rather than adherence to a pre-defined
subset.
-- Scott
∂14-Oct-84 0800 WHOLEY@CMU-CS-C.ARPA Inconsistency in Aluminum edition
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Oct 84 07:59:58 PDT
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sun 14 Oct 84 11:00:47-EDT
Date: Sun, 14 Oct 1984 11:00 EDT
Message-ID: <WHOLEY.12055380092.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Inconsistency in Aluminum edition
The text describing PUSHNEW (p. 270) and that describing ADJOIN (p. 276) are
apparently in contradiction.
"The keyword arguments to PUSHNEW follow the conventions for generic
sequence functions. See chapter 14. In effect, these keywords are
simply passed on to the ADJOIN function."
"ADJOIN deviates from the usual rules described in chapter 14 for the
treatment of the arguments named ITEM and KEY. If a KEY function is
specified, it is applied to ITEM as well as to each element of the
list."
Which should one believe?
--Skef
∂14-Oct-84 0822 FAHLMAN@CMU-CS-C.ARPA Inconsistency in Aluminum edition
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 14 Oct 84 08:22:22 PDT
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sun 14 Oct 84 11:23:12-EDT
Date: Sun, 14 Oct 1984 11:23 EDT
Message-ID: <FAHLMAN.12055384182.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Skef Wholey <Wholey@CMU-CS-C.ARPA>
Cc: Common-Lisp@SU-AI.ARPA
Subject: Inconsistency in Aluminum edition
In-reply-to: Msg of 14 Oct 1984 11:00-EDT from Skef Wholey <Wholey>
Certainly PUSHNEW and ADJOIN behave the same way with respect
to the :KEY argument, namely the way ADJOIN does this.
The manual should be tweaked to make this absolutely clear.
-- Scott
∂15-Oct-84 0706 OHLANDER%usc-isi.arpa@csnet-relay.arpa Re: World peace
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 15 Oct 84 07:04:45 PDT
Received: from usc-isi.arpa by csnet-relay.arpa id a003721; 15 Oct 84 8:41 EDT
Date: 15 Oct 1984 08:39-EDT
Sender: OHLANDER%usc-isi.arpa@csnet-relay.arpa
Subject: Re: World peace
From: OHLANDER%usc-isi.arpa@csnet-relay.arpa
To: GRISS%hplabs.csnet%csnet-relay.arpa@csnet-relay.arpa
Cc: Fahlman%cmu-cs-c.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: quinquevirate%su-ai.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: ohlander%usc-isi.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: squires%usc-isi.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: fateman%ucb-vax.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: griss.hplabs%csnet-relay.arpa%csnet-relay.arpa@csnet-relay.arpa
Cc: shiel.pa%xerox.arpa%csnet-relay.arpa@csnet-relay.arpa
Message-ID: <[USC-ISI.ARPA]15-Oct-84 08:39:32.OHLANDER>
In-Reply-To: <8410121125.AA05351@HP-VENUS>
Martin,
Received the message.
Ron
∂17-Oct-84 1206 Moon@SCRC-QUABBIN.ARPA Re: Questions about OPEN
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 12:06:40 PDT
Received: from SCRC-EUPHRATES by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 92185; Wed 17-Oct-84 15:03:59-EDT
Date: Wed, 17 Oct 84 15:04 EDT
From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Subject: Re: Questions about OPEN
To: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Cc: RAM@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA,
heller%umass-cs.csnet@CSNET-RELAY.ARPA
In-reply-to: The message of 5 Oct 84 13:09-EDT from Charles Hedrick <HEDRICK at RUTGERS>
Date: 5 Oct 84 13:09:40 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
On the DEC-20 it would certainly be better to maintain the distinction
between filename and stream. A common strategy for an editor is to
write a new copy of a file with a temporary file name, close it, and
then rename it on top of the original. This minimizes the probability
of damage in a crash. One would prefer to use the same JFN for this
entire process. A JFN is a small integer that is a handle on a file.
If you keep the JFN active, you are sure that nobody else is going to
rename the file out from under you or do anything else nefarious.
This is easy if all of the operations can be done on streams. My
feeling is that the distinction makes sense on some OS's, and on
others causes no harm (other than extra code), so it should be kept.
-------
I think the point here is that you don't write such an editor in Common Lisp by
generating a temporary file name yourself (how do you make the file name syntax
for such temporary files portable across implementations with different maximum
file name lengths and different legal characters to appear in file names?),
calling OPEN, calling CLOSE, and calling RENAME-FILE. Instead, you call
OPEN in :IF-EXISTS :SUPERSEDE mode, and the implementation takes care of doing
whatever combination of OPEN's, CLOSE's, and RENAME's is appropriate for the
particular file system. Your editor might want to check
(eq (pathname-version pathname) ':newest),
which is an implementation-independent operation, before deciding whether
to use supersede mode. In Unix, where there are no version numbers, that
EQ test will always be false, you will always use supersede mode, and everything
will be fine.
∂17-Oct-84 2251 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 17 Oct 84 22:51:19 PDT
Received: from SPA-RUSSIAN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 110774; Thu 18-Oct-84 01:52:59-EDT
Date: Wed, 17 Oct 84 22:49 PDT
From: rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA
Sender: rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA
Subject: Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
To: common-lisp@SU-AI.ARPA
Supersedes: The (misaddressed) message of 17 Oct 84 02:47-PDT from Bill Gosper <rwg%SPA-NIMBUS at SCRC-STONY-BROOK>
(cc:bug-lispm@scrc,lisp-designers@scrc)
In Symbolics 3600 System 242.355, Mailer 41.3, Print 34.3,
Macsyma 23.103, microcode TMC5-MIC 297, on Russian:
For what my opinion is worth, it was massively wrong for SIGNUM to try to
preserve the floatingness of its argument. The whole purpose of the
function is to reduce the information content of its arg to the minimum.
Can anyone recall the rationale? Was it any better than the "contagious
floating" creeping braindamage? When you get an exact answer, it is
idiotic to cast it into the one grubby datatype that fosters inexact
computation. Maybe what you're trying to say is "this SIGNUM was
of a datum so wretched that even its sign was probably wrong"?
>>Error: Page fault on unallocated VMA 206060064
While in the function SYS:%LEXPR-AREF _ AREF _ TRIANGLE-WINDING-OF-ORIGIN
SYS:%LEXPR-AREF: (P.C. = 271)
Arg 0 (ARRAY): #<ART-Q-3-3-3 22060054>
Arg 1 (INDICES): (2.0 2.0 2.0)
Local 2 (NDIMS): 3
Local 3 (DATA-POINTER): #<DTP-LOCATIVE 22060064>
Local 4 (LINEAR-INDEX): 26.0
Local 5 (TYPE): 5
Local 6 (BITS-PER-ELEM): NIL
Local 7 (ELEMS-PER-Q): 1
AREF: (P.C. = 10)
Arg 0 (ARRAY): #<ART-Q-3-3-3 22060054>
Rest arg (SUBSCRIPTS): (2.0 2.0 2.0)
TRIANGLE-WINDING-OF-ORIGIN: (P.C. = 42)
Arg 0 (X0): -1
Arg 1 (Y0): -0.9999
Arg 2 (X1): 0
Arg 3 (Y1): -0.9999
Arg 4 (X2): 1
Arg 5 (Y2): 1.0001
TRIANGLE-WINDING-OF-ORIGIN: (encapsulated for TRACE)
Rest arg (ARGLIST): (-1 -0.9999 0 -0.9999 1 1.0001)
POLYGON-WINDING-NUMBER: (P.C. = 42)
Arg 0 (PX): 1
Arg 1 (PY): 0.9999
Arg 2 (FIRST-X): 0
Arg 3 (FIRST-Y): 0
Rest arg (COORDS): (1 0 2 2 0 1)
SI:*EVAL: (P.C. = 370)
Arg 0 (FORM): (POLYGON-WINDING-NUMBER 1 0.9999 0 0 1 0 2 2 0 ...)
SI:LISP-COMMAND-LOOP-INTERNAL: (P.C. = 200)
Rest arg: (:NAME "Lisp Top Level in Lisp Listener 1" :ABORTED-FUNCTION NIL :BEFORE-PROMPT-FUNCTION NIL :READ-FUNCTION NIL :EVAL-FUNCTION NIL ...)
SI:LISP-COMMAND-LOOP: (P.C. = 115)
Arg 0 (STREAM): #<LISP-LISTENER Lisp Listener 1 23600000 exposed>
Rest arg: (:NAME "Lisp Top Level in Lisp Listener 1")
Rest of stack:
SI:LISP-TOP-LEVEL1: (P.C. = 22)
SI:LISP-TOP-LEVEL: (P.C. = 7)
∂18-Oct-84 0105 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 18 Oct 84 01:04:21 PDT
Received: from SPA-RUSSIAN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 110817; Thu 18-Oct-84 04:05:56-EDT
Date: Thu, 18 Oct 84 01:02 PDT
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
Subject: Why dosen't SIGNUM preserve a few exponent and fraction bits while it's at it?
To: DCP@SCRC-STONY-BROOK.ARPA
Cc: BUG-LISPM@SCRC-STONY-BROOK.ARPA,
lisp-designers%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA,
common-lisp@SU-AI.ARPA, ddyer%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA,
cwr%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA
In-reply-to: <841017111351.8.DCP@NEPONSET.SCRC.Symbolics>
Date: Wednesday, 17 October 1984, 11:13-EDT
From: David C. Plummer <DCP at SCRC-TENEX>
Date: Wed, 17 Oct 84 02:47 PDT
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
In Symbolics 3600 System 242.355, Mailer 41.3, Print 34.3,
Macsyma 23.103, microcode TMC5-MIC 297, on Russian:
For what my opinion is worth, it was massively wrong for SIGNUM to try to
preserve the floatingness of its argument. The whole purpose of the
function is to reduce the information content of its arg to the minimum.
Can anyone recall the rationale? Was it any better than the "contagious
floating" creeping braindamage? When you get an exact answer, it is
idiotic to cast it into the one grubby datatype that fosters inexact
computation. Maybe what you're trying to say is "this SIGNUM was
of a datum so wretched that even its sign was probably wrong"?
What does this have to do with SIGNUM? The bug you SHOWING is that
%LEXPR-[AREF/ASET/ALOC] don't type check their indices.
>>Error: Page fault on unallocated VMA 206060064
While in the function SYS:%LEXPR-AREF _ AREF _ TRIANGLE-WINDING-OF-ORIGIN
SYS:%LEXPR-AREF: (P.C. = 271)
Arg 0 (ARRAY): #<ART-Q-3-3-3 22060054>
Arg 1 (INDICES): (2.0 2.0 2.0)
Local 2 (NDIMS): 3
Local 3 (DATA-POINTER): #<DTP-LOCATIVE 22060064>
Local 4 (LINEAR-INDEX): 26.0
Local 5 (TYPE): 5
Local 6 (BITS-PER-ELEM): NIL
Local 7 (ELEMS-PER-Q): 1
Sorry to have been so garbled. I guess I expected everyone to figure out that I
subscripted by the 1+ of SIGNUMs. The error was especially traumatic since we had
just swapped the DP board in an apparently successful attempt to fix a
longstanding problem with EGC and FULL-GC, and I had just run them! Halloween
came early this year.
PS: If it didn't cost anything to check and FIX the subscripts, floating integer
subscripts should work! Actually, there shouldn't be floating integers! CommonSlip's
"rule of rational canonicalization" should convert them (if possible), to fixnums!
-0.0 be damned! My keyboard is melting!
∂21-Oct-84 2152 GS70@CMU-CS-A.ARPA SIGNUM in integer form
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Oct 84 21:52:02 PDT
Date: 22 Oct 84 0047 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
To: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
Subject: SIGNUM in integer form
CC: common-lisp@SU-AI.ARPA
In-Reply-To: "Bill Gosper's message of 18 Oct 84 03:02-EST"
Maybe what you want is the third value from INTEGER-DECODE-FLOAT?
(Not the most elegant thing, I admit.)
--Guy
∂21-Oct-84 2152 GS70@CMU-CS-A.ARPA SIGNUM and brain damage
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 21 Oct 84 21:51:52 PDT
Date: 22 Oct 84 0042 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
To: rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA
Subject: SIGNUM and brain damage
CC: common-lisp@SU-AI.ARPA
In-Reply-To: "rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA's message of 18 Oct 84
00:49-EST"
I'm probably guilty here, if guilt there be. Floating-point contagion
may have been the disease, but remember also that Common Lisp adopted
the APL extension to SIGNUM, namely that SIGNUM of a complex number
returns that point on the unit circle on the ray from the origin to
the argument (or zero if the argument is zero). That lent more impetus
to following the usual contagion rules (both floating and complex).
It also allows the following fairly elegant definition:
(defun signum (x) (if (zerop x) x (/ x (abs x))))
--Guy
∂22-Oct-84 1440 AS%hp-hulk.csnet@csnet-relay.arpa Should (EVAL-WHEN (EVAL LOAD) mumble) = mumble?
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 22 Oct 84 14:40:11 PDT
Received: from hplabs by csnet-relay.csnet id al00222; 22 Oct 84 17:29 EDT
Received: by HP-VENUS id AA24895; Mon, 22 Oct 84 11:15:18 pdt
Message-Id: <8410221815.AA24895@HP-VENUS>
Date: 22 Oct 1984 1115-PDT
From: AS%hplabs.csnet@csnet-relay.arpa
Subject: Should (EVAL-WHEN (EVAL LOAD) mumble) = mumble?
To: Common-Lisp%su-ai.arpa@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
As far as I can tell from reading the definition of EVAL-WHEN, the form
(EVAL-WHEN (EVAL LOAD) mumble) is always equivalent to an unadorned mumble.
Specifically, if the interpreter sees this EVAL-WHEN, it will evaluate mumble
(since EVAL is specified); if the compiler sees this EVAL-WHEN, it will
process mumble in the same mode as the EVAL-WHEN form (either NOT-COMPILE-TIME
or COMPILE-TIME-TOO). In either case, the interpreter and compiler process
mumble just as they would if mumble appeared by itself, without being wrapped
in EVAL-WHEN. Does anyone disagree with this interpretation of the
definition?
If this interpretation of the definition is correct, then I would argue that
the definition is not the right one. PSL has a similar notion called
LOADTIME, but its effect is different. Specifically, (LOADTIME mumble)
instructs the compiler as follows: (1) If mumble would normally be evaluated
at compiletime, then do not perform that evaluation; (2) generate code to
evaluate mumble at load-time, even if such code would not normally be
generated. In Common Lisp terms, assuming this macro definition,
(DEFMACRO FOO () `(EVAL-WHEN (EVAL COMPILE) (*FOO)))
the form
(EVAL-WHEN (EVAL LOAD) (FOO))
would NOT invoke *FOO at compile time, and WOULD generate code to invoke *FOO
at load time. (In the PSL example I actually encountered, FOO was not a
macro, but a function flagged as implicitly EVAL-COMPILE.)
Alan Snyder
hplabs!snyder
-------
∂25-Oct-84 1012 RPG Change of address
∂19-Oct-84 0326 brown@DEC-HUDSON Change of address
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 19 Oct 84 03:25:48 PDT
Date: Fri, 19 Oct 84 06:22:23 EDT
From: brown@DEC-HUDSON
Subject: Change of address
To: rpg@su-ai
Dick,
Would you make a few changes to the distributions:
1) Change my address for the main distribution list, and the
distribution lists for the charter, validation, window, graphics
and subsets committees from GBrown@DEC-Marlboro to
Brown@DEC-Hudson (no G).
2) Add Boetje@DEC-Hudson to the windows and graphics committees.
(Jerry Boetje will be doing this work for us so we can have
a work-station too.)
3) Add Greek@DEC-Marlboro to the iteration committee.
(Paul Anagnostopolous.)
Flip your three sided coin and let us know who will chair the validation
committee.
-Gary
Done on the mailing lists. I will choose amongst the candidates
tomorrow.
∂26-Oct-84 1046 GREEK@DEC-MARLBORO.ARPA Daylight Saving Time
Received: from DEC-MARLBORO.ARPA by SU-AI.ARPA with TCP; 26 Oct 84 10:46:14 PDT
Date: Fri 14 Sep 84 14:56:44-EDT
From: GREEK@DEC-MARLBORO.ARPA
Subject: Daylight Saving Time
To: common-lisp@SU-AI.ARPA
I hate to beat a horse which everyone wishes were dead, but:
What should DECODE-UNIVERSAL-TIME do about daylight saving time?
Clearly, ENCODE-UNIVERSAL-TIME takes it into accout, if appropriate, when
normalizing to GMT. When decoding, however, who knows if the original time
was on daylight saving time? And if decoding into a different time zone, who
knows if that zone is on daylight saving time? At the very least,
DECODE-UNIVERSAL-TIME has no business returning daylight-saving-time-p.
In VAX LISP, we take daylight saving time in account when decoding into
the local time zone, and in no other case. This means that if a local
time is encoded and then decoded in California, it's off by one hour.
I think our algorithm is bogus, but I'm not sure what to do.
- Paul
-------
∂26-Oct-84 1729 AS%hp-hulk.csnet@csnet-relay.arpa EVAL-WHEN: question about intent
Received: from CSNET-RELAY.ARPA by SU-AI.ARPA with TCP; 26 Oct 84 17:29:12 PDT
Received: from hplabs by csnet-relay.csnet id am00718; 26 Oct 84 20:11 EDT
Received: by HP-VENUS id AA26468; Fri, 26 Oct 84 12:57:48 pdt
Message-Id: <8410261957.AA26468@HP-VENUS>
Date: 26 Oct 1984 1257-PDT
From: AS%hplabs.csnet@csnet-relay.arpa
Subject: EVAL-WHEN: question about intent
To: Common-Lisp%su-ai.arpa@csnet-relay.arpa
Source-Info: From (or Sender) name not authenticated.
Despite Guy Steele's improvements, I believe the definition of EVAL-WHEN in
the published definition is still fuzzy and the intent is not clear. The
purpose of this message is to outline the nature of this fuzziness and request
opinions from designers and users regarding use of EVAL-WHEN. The issue
raised by this message is distinct from the issue I raised in a recent message
(to which I have not seen any replies).
--------------------------------------------------------------------------------
There are two different, but related characteristics that one might want to
control using EVAL-WHEN.
Characteristic 1: Direct Evaluation vs. Making a Compiled File
A. Making a "compiled" file involves processing a collection of
forms and producing a file that later can be loaded to achieve the
effect of evaluating those forms. In this case, there are two clearly
distinct "times" (when the file is being made and when it is being
loaded) and potentially two distinct environments. Note that making a
"compiled file" need not involve the generation of "machine code",
although it is presumed to involve "reading the file" (and invoking
readmacros) and "expanding macros", two activities where the Common Lisp
manual explicitly mentions that EVAL-WHEN may be required.
B. The alternative is "direct evaluation" (for side-effect and
result). As stated on page 321, direct evaluation can be performed by
an interpreter, or by compiling the form into some other representation
(such as "machine code") and then interpreting this representation
(perhaps by "hardware"). In this case, there is only one "time" as far
as the user is concerned, and only one evironment; one may have the
choice of either "doing it" or "not doing it", but there is no choice as
to "where it is done", and in no case should "it be done twice".
Characteristic 2: Compilation vs. Interpretation
A. In this sense, "compilation" presumably refers to generating
"machine code", although this notion may be meaningless or ambiguous in
any particular implementation. One could argue that even an interpreter
that uses a preprocessor should be considered to be a "compiler", since
it transforms the program before executing it.
B. The alternative, "interpretation", presumably refers to a
technique for evaluation that is not a "compiler", as described above.
Some implementations may not offer this alternative.
In my view, Characteristic 1 is well defined and useful, but Characteristic 2
is fuzzy to the point of being useless, especially in light of the variety of
possible implementation techniques for evaluation (explicitly permitted on
page 321).
Unfortunately, the definition of EVAL-WHEN refers to both characteristics.
The "COMPILE" and "LOAD" situations for EVAL-WHEN are clearly defined in terms
of compiling a file (Characteristic 1). However, the definition of the "EVAL"
situation refers to interpreting versus compilation (which sounds like
Characteristic 2).
I do not know what the motivation is for attempting to use EVAL-WHEN to
control what happens during direct evaluation. PSL does not provide such a
feature: it assumes that regardless of what is desired when making or loading
a compiled file, one always wants to "do it" (once) when directly evaluating.
I would prefer to omit this "EVAL" situation entirely from Common Lisp.
However, it is there, and presumably there are reasons for it. What are they?
Where would you use this control? Which characteristic (as described above)
are you attempting to select for when you use EVAL-WHEN? We must decide which
one it is (it can't be both).
--------------------------------------------------------------------------------
Alan Snyder
hplabs!snyder
-------
∂26-Oct-84 1836 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA SIGNUM in integer form
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Oct 84 18:36:09 PDT
Received: from SPA-RUSSIAN by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 115582; Fri 26-Oct-84 02:46:33-EDT
Date: Thu, 25 Oct 84 23:47 PDT
From: Bill Gosper <rwg@NIMBUS.SPA.Symbolics>
Subject: SIGNUM in integer form
To: Guy.Steele@CMU-CS-A.ARPA
Cc: common-lisp@SU-AI.ARPA
In-reply-to: The message of 21 Oct 84 21:47-PDT from Guy.Steele@CMU-CS-A.ARPANET
Date: 22 Oct 84 0047 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
Maybe what you want is the third value from INTEGER-DECODE-FLOAT?
(Not the most elegant thing, I admit.)
--Guy
No, for 1.5 reasons:
1) It doesn't return 0 for 0.
1.5) It isn't documented what happens for integer arg.
Semi-apropos those pages, I really wish there were SCALE-BY-POWER-OF-2,
which various implementations could do much faster than
multiplication, for almost any representation of any kind of number.
SCALE-FLOAT can't do this because of hexadecimal affirmative action,
and having the wrong name.
∂03-Nov-84 0750 rwg%NIMBUS.SPA.Symbolics@SCRC-RIVERSIDE.ARPA SIGNUM and brain damage
Received: from SCRC-RIVERSIDE.ARPA by SU-AI.ARPA with TCP; 3 Nov 84 07:50:40 PST
Received: from SPA-RUSSIAN by SCRC-RIVERSIDE via CHAOS with CHAOS-MAIL id 25744; Sat 3-Nov-84 10:51:10-EST
Date: Sat, 3 Nov 84 07:44 PST
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
Subject: SIGNUM and brain damage
To: Guy.Steele@CMU-CS-A.ARPA
Cc: common-lisp@SU-AI.ARPA, mlb%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA
In-reply-to: The message of 21 Oct 84 21:42-PDT from Guy.Steele at CMU-CS-A
Date: 22 Oct 84 0042 EDT (Monday)
From: Guy.Steele@CMU-CS-A.ARPA
In-Reply-To: "rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA's message of 18 Oct 84 00:49-EST"
I'm probably guilty here, if guilt there be. Floating-point contagion
may have been the disease, but remember also that Common Lisp adopted
the APL extension to SIGNUM, namely that SIGNUM of a complex number
returns that point on the unit circle on the ray from the origin to
the argument (or zero if the argument is zero). That lent more impetus
to following the usual contagion rules (both floating and complex).
It also allows the following fairly elegant definition:
(defun signum (x) (if (zerop x) x (/ x (abs x))))
--Guy
Well, I hardly think invoking divide is elegant, and the complex numbers are
broken without complex infinity, which is phaseless, and must therefore
constitute a fourth value of signum, but that's another story.
A much cruftier corollary of floating contagion shows up in min and max.
It is a contradiction to say "max returns the argument that is greatest ..."
and then in the next sentence say "the implementation is free to produce
... [some rational's] floating point approximation". Such an approximation
is generally not any of the arguments, or worse, it may even by = to an argument
that was not the largest!
∂04-Nov-84 0428 GSB@MIT-MC cruftier contagion corollaries cause consternation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 4 Nov 84 04:28:29 PST
Date: 4 November 1984 07:30-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: cruftier contagion corollaries cause consternation
To: common-lisp @ SU-AI, mlb%SPA-NIMBUS @ SCRC-STONY-BROOK
cc: Guy.Steele @ CMU-CS-A, rwg%SPA-NIMBUS @ SCRC-STONY-BROOK
Date: Sat, 3 Nov 84 07:44 PST
From: Bill Gosper <rwg%SPA-NIMBUS@SCRC-STONY-BROOK.ARPA>
. . .
A much cruftier corollary of floating contagion shows up in min
and max. It is a contradiction to say "max returns the argument
that is greatest ..." and then in the next sentence say "the
implementation is free to produce ... [some rational's] floating
point approximation". Such an approximation is generally not any
of the arguments, or worse, it may even by = to an argument that
was not the largest!
Yum, it can be even worse with things like multiple-argument =.
There can be two rationals R1 and R2 which are different but both
= to some float F. So, (= r1 r2 f) would be true if it was done
as (= (float r1) (float r2) f), i.e. do contagious coercion of all args
before doing anything else, but not if it was done as
(and (= r1 r2) (= r2 f)). What would your users think if
(= r1 r2 f) was T in when run in NIL compiled and in Spice
interpreted, and NIL when run in NIL interpreted and in Spice
compiled?
∂10-Nov-84 1657 @MIT-MC:KMP@MIT-OZ Using EQ instead of EQL to compare catch tags
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 10 Nov 84 16:56:48 PST
Date: Sat 10 Nov 84 18:29-EST
From: Kent M Pitman <KMP%MIT-OZ@MIT-MC.ARPA>
Subject: Using EQ instead of EQL to compare catch tags
To: COMMON-LISP@SU-AI
Is there a reason why EQ was chosen instead of EQL for comparing CATCH
tags? It seems to me that signalling errors isn't likely to be so blindingly
fast that using EQL instead of EQ would slow it down enough to matter,
and it would simplify the definition (top of p140) to use EQL, wouldn't it?
This would be an upward compatible change.
-kmp
∂10-Nov-84 1730 FAHLMAN@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Nov 84 17:30:33 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 10 Nov 84 20:30:52-EST
Date: Sat, 10 Nov 1984 20:30 EST
Message-ID: <FAHLMAN.12062572668.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP%MIT-OZ@MIT-MC.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Using EQ instead of EQL to compare catch tags
In-reply-to: Msg of 10 Nov 1984 18:29-EST from Kent M Pitman <KMP%MIT-OZ at MIT-MC.ARPA>
Catch/Throw is not just for signalling errors. It is used quite a bit
in our interpreter, and therefore needs to be moderately fast. EQL is
considerably slower than EQ on stock hardware, and this speed advantage,
though not terribly important, seemed to be more important than letting
people use numbers as catch-tags.
-- Scott
∂10-Nov-84 1738 WHOLEY@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 10 Nov 84 17:37:56 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Sat 10 Nov 84 20:37:58-EST
Date: Sat, 10 Nov 1984 20:37 EST
Message-ID: <WHOLEY.12062573973.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP%MIT-OZ@MIT-MC.ARPA>
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Using EQ instead of EQL to compare catch tags
From: Kent M Pitman <KMP%MIT-OZ at MIT-MC.ARPA>
Is there a reason why EQ was chosen instead of EQL for comparing CATCH
tags? It seems to me that signalling errors isn't likely to be so
blindingly fast that using EQL instead of EQ would slow it down enough to
matter, and it would simplify the definition (top of p140) to use EQL,
wouldn't it? This would be an upward compatible change.
Spice Lisp (and perhaps other implementations) would have trouble with that
change of definition. In our case, the microcode knows only about fixnums and
short floats (immediate numbers for us), and escapes to macrocode routines for
arithmetic (and comparison) operations involving other sorts of numbers. Throw
is implemented in microcode on the Perq, so if the Throw instruction was given
a bignum tag and ran into a bignum tag on the stack, it would have to escape to
macrocode to do the comparison.
But our macrocode escape machanism is designed to work only on instruction
boundaries, so there wouldn't be any clean way to get back into microcode to
continue the throw. I could certainly add some kludge to the Perq microcode to
deal with the EQL test, but since there are other imlementations out there with
tense EQ'ing loops in microcode, assembly code, Bliss, or whatever, I don't
think the change is worth the trouble. Also, there would be some loss of
performance on stock hardware by putting the EQL into the inner loop of throw.
--Skef
∂12-Nov-84 1012 Masinter.pa@Xerox.ARPA Re: Using EQ instead of EQL to compare catch tags
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 10:12:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 NOV 84 10:13:23 PST
Date: 12 Nov 84 10:04 PST
From: Masinter.pa@XEROX.ARPA
Subject: Re: Using EQ instead of EQL to compare catch tags
In-reply-to: Skef Wholey <Wholey@CMU-CS-C.ARPA>'s message of Sat, 10 Nov
84 20:37 EST
To: COMMON-LISP@SU-AI.ARPA
It seems clear that the "portable subset" of Common Lisp has to either
insist that EQL be used for catch-tags, or else refuse to allow anything
other than a symbol.
There *are* some performance penalties for portability, you know....
∂12-Nov-84 1051 WHOLEY@CMU-CS-C.ARPA Using EQ instead of EQL to compare catch tags
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 10:51:37 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Mon 12 Nov 84 13:51:20-EST
Date: Mon, 12 Nov 1984 13:51 EST
Message-ID: <WHOLEY.12063024238.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Masinter.pa@XEROX.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Using EQ instead of EQL to compare catch tags
In-reply-to: Msg of 12 Nov 1984 13:04-EST from Masinter.pa at XEROX.ARPA
From: Masinter.pa at XEROX.ARPA
To: COMMON-LISP at SU-AI.ARPA
It seems clear that the "portable subset" of Common Lisp has to either
insist that EQL be used for catch-tags, or else refuse to allow anything
other than a symbol.
That makes very little sense to me. Non-symbol, non-numeric catch tags are
useful. For example, to correctly implement the contorted example on page 40,
one must create a unique catch tag at runtime (that's done quickly and portably
with CONS). The only place I can imagine numeric catch tags being used is in
code generated by the compiler or some program-writing-program. In either
case, care can be taken to make sure that the tag that's caught and the tag
that's thrown are EQ.
There *are* some performance penalties for portability, you know....
Yeah, but Common Lisp tries to give a reasonable amount of flexibility to the
implementor. Given the whole EQ not working on numbers business, I don't think
there's much more cognitive load on the programmer.
It's probably time for people to start realizing that there are real Common
Lisp implementations supporting real users Right Now. Take a look at the
Stability paragraph on page 3.
--Skef
∂12-Nov-84 1224 KMP@MIT-MC catch/throw performance loss
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 12:24:43 PST
Date: 12 November 1984 15:25-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: catch/throw performance loss
To: common-lisp @ SU-AI
Of course, there could be two routines -- one optimized for EQ when it
works, and one for EQL when needed. Unless THROW sees a number or char,
it can use the fast routine, no? In which case, we're not talking
performance loss -- just implementation overhead.
In response to SKEF's remark about "Given the whole EQ not working on
numbers business, I don't think there's more cognitive load on the
programmer", I say I think he's confused. The point is that the user
(at least, me) is going to expect that implementors are going to take
their own advice and use EQL in places where EQ might be dangerous, and
this is such a place. It it undue burden on the programmer to have to
remember "EQ doesn't work on numbers, but I have to remember that THROW
will try to use it anyway, so I should be careful never to let THROW
try such a thing because a bug will bring my program down in flames".
It's holes in the language like this that drive users crazy.
∂12-Nov-84 1251 FAHLMAN@CMU-CS-C.ARPA catch/throw performance loss
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 12:51:05 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 12 Nov 84 15:50:32-EST
Date: Mon, 12 Nov 1984 15:50 EST
Message-ID: <FAHLMAN.12063045938.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Kent M Pitman <KMP@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: catch/throw performance loss
All that random users need to remember is that Catch tags are supposed
to be symbols. We generalized it a bit beyond that, because we could do
this at *NO* extra implementation cost and it made some odd cases a bit
cleaner to use some fresh-consed object other than a symbol. But rather
than generalize to a case that IS going to cost more, I'd retreat to
allowing symbols only.
-- Scott
∂12-Nov-84 1328 JAR@MIT-MC Using EQ instead of EQL to compare catch tags
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 13:26:36 PST
Date: 12 November 1984 16:08-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject: Using EQ instead of EQL to compare catch tags
To: Wholey @ CMU-CS-C
cc: COMMON-LISP @ SU-AI
Date: Mon, 12 Nov 1984 13:51 EST
From: Skef Wholey <Wholey at CMU-CS-C.ARPA>
Non-symbol, non-numeric catch tags are useful. For example, to
correctly implement the contorted example on page 40, one must
create a unique catch tag at runtime (that's done quickly and
portably with CONS).
Not true. General BLOCK and RETURN-FROM do not need to be implemented
using CATCH/THROW. (It might actually make sense to do it just the
other way around, as is done in a Lisp implementation I won't name.)
Fine if an implementation does so, but such implementation detail
needn't enter into discussions of language design (or manual revision).
I suspect that any use of non-symbol CATCH could just as easily be
implemented using BLOCK and lexical closures. Just to add my two cents
worth, I tend to think of CATCH as a binding form, and therefore think
it should work on the same kinds of things that PROGV works on, but it's
probably too late to make this consistent (either by allowing variables
named by non-symbols or by forbidding non-symbol CATCH tags). And given
that non-symbol tags are allowed, and that there needn't be any
performance penalty (as Kent rightly points out), the EQL definition is
the right thing.
Jonathan
∂12-Nov-84 1341 JonL.pa@Xerox.ARPA EQ vs EQUAL: catch/throw performance loss
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 13:40:21 PST
Received: from Cabernet.MS by ArpaGateway.ms ; 12 NOV 84 13:41:31 PST
Date: 12 Nov 84 13:40 PST
From: JonL.pa@XEROX.ARPA
Subject: EQ vs EQUAL: catch/throw performance loss
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
Mon, 12 Nov 84 15:50 EST
To: Fahlman@CMU-CS-C.ARPA
cc: KMP@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
I like your rationalization of this: ". . . Catch tags are supposed to
be symbols. We generalized it a bit beyond that, because we could do
this at *NO* extra implementation cost and it made some odd cases a bit
cleaner . . .". This would permit a random list cell to be a catch tag,
but the THROW primitives would not be required to call EQUAL. The call
to use EQL would make more sense if it were a call to use EQUAL, because
fewer exceptions would have to be remembered, but then the cost factor
would come in to play again.
An underlying problem, however, is the deeper one of EQ semantics, and I
don't feel it is as bad as has been generally portrayed. Namely,
contrary to the prevalent proverb, EQ does work on numbers, and a user
can in fact so use it. What a user must understand is the more
complicated semantics of EQ as opposed to EQUAL -- a burden placed upon
him from the very beginnings of LISP 1.5. Here's a simple paraphrase of
the problems in Common Lisp which he must understand:
(1) two instances of a symbol FOO might not be EQ if they are interned
on
different packages, or if at least one of them is uninterned. [so what
is the identity of a "symbol" then? one would like to define it with
EQ,
but one cannot ignore that english language communication typically
defines
it by the characters of its pname, which is why one would would have to
say,
e.g., "ess-eye-colon-FOO" if the package distinction were important].
(2) two instances of any heap-consed object will not be EQ unless
stored at the
same address; while the notion of "address" isn't really
machine-dependent,
the notion of when one has two EQUAL but not EQ objects is very program
dependent, and there are very few constraints upon documented Common
Lisp
functions to preserve EQness.
(3) the compiler may, at its discretion, convert a pdl-allocated
object into
a heap-consed one of the same form (i.e., they must be EQUAL). So you
have
to know the potential range of pdl-allocation of your particular
implementtion.
(4) numbers aren't the only objects with EQ problems due to
pdl-allocation;
although I don't remember if the Common Lisp manul comments on this
question,
it has been true for a long time that the MIT Lisp Machine descendents
do
pdl-allocation for the &rest argument to functions, and don't protect
against
this quantity being pointed to by heap structures. Thus even a program
which
is itself free of updatings could find itself with two items which are
EQ
but not EQUAL! [the "two items" here are not two program variables, but
the
same program variable at two different times]. I suspect that a simple
bit of
compiler technology is called for here.
-- JonL --
∂12-Nov-84 2040 GSB@MIT-MC catch/throw performance loss
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 20:40:45 PST
Date: 12 November 1984 23:24-EST
From: Glenn S. Burke <GSB @ MIT-MC>
Subject: catch/throw performance loss
To: common-lisp @ SU-AI
The fact that catch/throw don't use EQL has always bothered me as a
consistency hole. I think they should. I also don't believe that
the tags should be restricted to symbols. To do this in NIL throw
will have to check to see if it can do the fast EQ lookup -- this is
a fairly trivial check. I also have some problems with doing hairy
EQL lookup in THROW, but they have to do with maintaining the pointer
to the catch-frame chain during the lookup, because it isn't an explicit
data-type, and EQL can call out to the user.
∂12-Nov-84 2122 WHOLEY@CMU-CS-C.ARPA Stability?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 21:22:49 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 13 Nov 84 00:22:36-EST
Date: Tue, 13 Nov 1984 00:22 EST
Message-ID: <WHOLEY.12063139164.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA
Subject: Stability?
It seems that if X is implemented as specified, but X is subject to debate,
then the specification of X should not change. Some people are making appeals
to taste, but there are other less tasteful features of the language that no
one's trying to change. Should CMU and DEC and Data General and Symbolics and
whoever else out there be forced to reimplement something because it's not as
tasteful (in someone's opinion -- not everyone's) as could be?
Sure, the compiler could easily figure out where an EQ-Throw could be used.
I'll go and fix our implementation if everyone thinks I should. But that's not
my idea of a stable language specification.
Hey, why not have Throw take a keyword argument for the test to use? Or an
abitrary predicate that the tag must satisfy? Other keyword arguments would be
useful as well...
(unless (throw *zinger* 'hi! :test #'equalp :if-does-not-exist nil)
(format t "Catch tag ~S was not found.~%" *zinger*))
--Skef
∂12-Nov-84 2347 masinter.pa@Xerox.ARPA Re: Stability?
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 12 Nov 84 23:47:25 PST
Received: from Chardonnay.ms by ArpaGateway.ms ; 12 NOV 84 23:47:50 PST
From: masinter.pa@XEROX.ARPA
Date: 12 Nov 84 23:47:00 PST
Subject: Re: Stability?
In-reply-to: WHOLEY@CMU-CS-C.ARPA's message of Tue, 13 Nov 84 00:22 EST,
<WHOLEY.12063139164.BABYL@CMU-CS-C.ARPA>
To: WHOLEY@CMU-CS-C.ARPA
cc: Common-Lisp@SU-AI.ARPA
If Common Lisp is a fundamentalist religion (the Aluminum Edition is the
Word of God) and not subject to debate, on grounds of taste, efficiency,
or portability, then please remove me from the DL -- any further
discussion is senseless.
I believe the issue about EQ vs EQL in Catch and Throw tags is *not* an
issue of taste, but rather an instance of one of the minor ways in which
"Common Lisp" could fail to meet one of its initial goals: being a
portable dialect. Insofar as a valid Common Lisp expression which is not
"it is an error" could work differently and unpredictably in one
implementation of the spec and another, then the language isn't portable
and "common" is a myth.
∂13-Nov-84 0036 WHOLEY@CMU-CS-C.ARPA Stability?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 13 Nov 84 00:36:11 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 13 Nov 84 03:36:01-EST
Date: Tue, 13 Nov 1984 03:35 EST
Message-ID: <WHOLEY.12063174370.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: masinter.pa@XEROX.ARPA
Cc: Common-Lisp@SU-AI.ARPA
Subject: Stability?
Insofar as a valid Common Lisp expression which is not "it is an error"
could work differently and unpredictably in one implementation of the spec
and another, then the language isn't portable and "common" is a myth.
The language specification is full of explicit concessions to different
implementation techniques. "(let ((x 5)) (eq x x))" is a program that could
yeild different results in different implementations (page 78). If you want to
question the funny nature of EQ, feel free. I think you'll come up against a
lot of opposition if you suggest that EQ be made to act like EQL. We've had
that discussion before, I believe.
But the nature of EQ wasn't being questioned. The choice of the predicate used
by Throw for comparing catch tags was. I don't think there's any person living
that thinks Common Lisp is the best programming language ever invented. There
are many people who think it's a good compromise between many different
language design issues. One should be able to write a correct Common Lisp
program today and have it run tomorrow. No, the language shouldn't be
stagnant, but it should change "only slowly and with due deliberation."
My point was that the Throw/EQ issue is a little thing, and there are many
other ugly little things in the language, but people have invested time and
money implementing them. As I said, if it's agreed that EQL is the best way to
compare catch tags, then I'll go along with that decision. But I wanted to
inject a little of the language's goal of stability into the discussion. A
programming language that changes in subtle ways overnight is far worse than
one with subtlties that are carefully documented.
--Skef
∂15-Nov-84 1121 RPG
∂14-Nov-84 2050 KSH@MIT-MC
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 14 Nov 84 20:50:08 PST
Date: 14 November 1984 23:50-EST
From: Kjeld Hvatum <KSH @ MIT-MC>
To: rpg @ SU-AI
Steve Bacher and I enjoyed your talk on Common Lisp at Intermetrics in
Cambridge. Could you put me on the mailing list for the latest Lisp
developments? We are particularly interested in Lisp developments for
the IBM 370 architecture, especially for MVS-XA (extended architecture
with 31 bit addressing). We are looking forward to your document on your
benchmarks. Thanks -Sandy (Kjeld Hvatum).
Done.
∂15-Nov-84 1126 RPG Common Lisp mailing lists
∂15-Nov-84 0744 J.Dalton%edxa@Ucl-Cs.ARPA Common Lisp mailing lists
Received: from [14.0.0.9] by SU-AI.ARPA with TCP; 15 Nov 84 07:43:52 PST
Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP
id a005123; 14 Nov 84 23:02 GMT
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date: Wednesday, 14-Nov-84 21:36:14-GMT
Message-ID: <131702-714-707@EDXA>
To: rpg <rpg%su-ai.arpa@ucl-cs.arpa>, J.Dalton%edxa@ucl-cs.arpa
Subject: Common Lisp mailing lists
--------
This is Jeff Dalton from the University of Edinburgh. I hope I'm
not being a pain by sending more or less the same thing twice, but
I'm afraid my earlier message may have been lost in transit (our
network connections are not always what they should be).
As you may recall, we met for an instant at the Lisp Conference and
I was going to drop in on you at Stanford the week after. Unfortunately,
you were home sick with the flu so that I ended up talking with
you by phone (thus saving the cost of a transatlantic call, I
suppose). Now that I'm back in Edinburgh and catching up on
everything that's happened while I was away, a couple of things
have again pointed me in your direction.
When I returned to Edinburgh (and was greeted by the expected rain
after my sunny stay in America), enthusiasm for Common Lisp had
noticeably increased. Some implementations have actually started,
and there is also talk of subsets (in which your "Critique" is
often cited). I understand from Scott Fahlman that there is a
Common Lisp mailing list and also one on subsets (after the meeting
in Monteray) and that you are the person to contact for these things.
Could I be added to these lists? One of my tasks is to keep track of
what's happening in Common Lisp and, since there is there is likely
to be some efforts towards developing a UK subset, what's happening
with subsets as well. It would be a shame if the UK Lisp community
were to diverge from the American when there's no need for it.
Also, I understand that the earlier Common Lisp discussions are kept
on-line at Stanford. Are they available for FTP?
When I was in California, you were distributing copies of a Common Lisp
compiler developed at Stanford and said you would be willing to send
me a tape. Since I had already left a note on your door at Stanford
requesting a tape of your benchmarks, I decided to rely on that to give
you my address; but since notes on doors are notoriously unreliable,
I've decided to ask again by electronic mail. If it is still possible
to send the benchmarks and the compiler, my address is:
Jeff Dalton
Department of Artificial Intelligence
(Applications Institute)
University of Edinburgh
Hope Park Square
Edinburgh EH8 9NW
(We've been moving offices, but this should reach me at my new address.
If anything, it has too much information.) The tape(s) should be
tar format, 1600 bpi (we have a VAX 750 running 4.2 BSD). We are quite
willing to pay a distribution fee if that is required and to abide by
any restrictions regarding use of the code. Of course, we would like it
best if the code could be used freely, including for commercial purposes.
Thanks, and good luck with Lucid,
Jeff Dalton
--------
∂15-Nov-84 1133 RPG Varia
To: Chailloux.INRIA@MIT-MULTICS.ARPA
CC: "#COMMON.MSG[COM,LSP]"@SU-AI.ARPA
Sorry for this long delay, but it took a while to accomplish the
long discussion with Scott Fahlman about kernels.
After a long discussion, in person, he sent the following messages
out:
****
The only need I see for a true subset is for small machines without
virtual memory, and even there they might get something approximating
the full language by a sort of autoload technique. In any event, such
system will be so tight that the builders will want to put in exactly
what their users need, and not some standard mix. For small expert
systems, you need one mix, for education you need another, if your
machine supports mouse-type graphics, another, if you want to build in
an Emacs, yet another. The speed-space tradeoffs are tricky, and
will be different for each tiny machine and each market. Maybe here and
there we will find cases enough alike that several manufacturers want to
agree on a common subset, or someone will set a de facto standard by
getting there first and doing a good job.
A different issue is the identification of a small kernel that, if you
can support it, you can load the rest of Common Lisp as portable code.
This is an interesting implementation technique, and we will be happy to
help people identify such kernels, but again the
time/space/coding-effort tradoff will be different for every machine,
depending on its constraints and whether it is trying to sit on top of
PSL, Interlisp, the raw hardware, or something else. Fortunately, no
standard is needed here, since on the surface all of these langauges
will look like real Common Lisp.
****
I'm not sure what the best course is, at the moment. I will put you on the
subsets mailing list, but I think that a subset along the lines I suggested
to you would be a good place to begin. Also, perhaps you should start a dialog
with Fahlman@cmuc and me on the topic.
-rpg-
∂16-Nov-84 2216 ME message remailed after list corrected
To: common-lisp@SU-AI.ARPA
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 16 Nov 84 16:52:16 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Fri 16 Nov 84 19:52:23-EST
Date: Fri, 16 Nov 1984 19:52 EST
Message-ID: <RAM.12064138549.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Inconsistency in CLM
There is an inconsistency in the CLM in the definition of Ceiling,
Floor, Truncate and Round in the explanation of the meaning of the
second argument. It is not in general true that:
(op x y) <==> (op (/ x y))
Consider Truncate with X = 1 and Y = -3/2:
(/ 1 -3/2) => -2/3
(truncate -2/3) => 0, -2/3
This result violates the formula describing the relation between the
return values and the arguments:
(+ (* 0 1) -2/3) => -2/3 ; Not 1!
While the first value of the two expressions will be the same, the
remainder is often different.
Rob
∂20-Nov-84 1857 REM%IMSSS.#Pup@SU-SCORE.ARPA How to organize portable programs with sys-dep parts?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 18:57:50 PST
Received: from IMSSS by Score with Pup; Tue 20 Nov 84 18:57:34-PST
Date: 19 Nov 1984 2255-PST
From: Rem@IMSSS
Subject: How to organize portable programs with sys-dep parts?
To: COMMON-LISP%SU-AI@SCORE
When writing code that will run on many systems, with most of the code
portable but a small part different on various systems, there comes
the problem of how to organise the various files that contain the
various parts of the code and how to link the portable code with the
system-dependent code. I'm wrestling with this currently in PSL, and
would be interested in hearing how Common LISP implementors did it, as
well as ideas from others. My ideas are below ("existing code" refers to
my IMSSS softare that is presently being ported to CMS and will soon
also be ported to other machines).
(1) The way my existing code does it, namely have all versions in the
source an all versions compiled, but at runtime a global
variable chooses each time which piece of code to execute
[advanges: simple;
disadvantages: confuses FCHECK; requires global variable at
runtime; takes a lot more memory at runtime; takes some more
time to execute each time; compilation takes much longer since
it has to compile everything for every machine every time]
(2) The same except using macros to select which body of code to compile
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: still requires versions of source for all systems
around when compiling for any system, thus taking longer to
read it in and slightly longer to select correct version to
compile; requires the macro to know what the target machine
will be, something I'm not sure the cross-compiler maks
available to user macros]
(3) Keep system-dependent stuff in separate files, using funny names
such as SYSDEP-foo as the way the system-dependent stuff is
called from the portable files, keep user-callable function in
portable source files with link to SYSDEP-foo function, and with
comments indicating where the SYSDEP-foo function might be found
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: (a) if functions used as linkage, slightly more
CPU time (b) if macros used as linkage, you won't be able to
TRace system functions by their usual name at runtime unless the
TRace package is smart enough to map (TRace OPEN) into (TRace
SYSDEP-OPEN) for example.]
(4) Same except have user call the system-dependent functions
directly, i.e. they have advertised names rather than funny
names via vector from advertised names
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: confusing to maintainers since they have no idea
whether a function is in portable files or in some random
system dependent file]
-------
∂20-Nov-84 1859 REM%IMSSS.#Pup@SU-SCORE.ARPA How to implement partly-system-dependent mostly-portable code?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 20 Nov 84 18:58:25 PST
Received: from IMSSS by Score with Pup; Tue 20 Nov 84 18:58:05-PST
Date: 20 Nov 1984 1241-PST
From: Rem@IMSSS
Subject: How to implement partly-system-dependent mostly-portable code?
To: COMMON-LISP%SU-AI@SCORE
When writing code that will run on many systems, with most of the code
portable but a small part different on various systems, there comes
the problem of how to organise the various files that contain the
various parts of the code and how to link the portable code with the
system-dependent code. I'm wrestling with this currently in PSL, and
would be interested in hearing how Common LISP implementors did it, as
well as ideas from others. My ideas are below ("existing code" refers to
my IMSSS softare that is presently being ported to CMS and will soon
also be ported to other machines).
(1) The way my existing code does it, namely have all versions in the
source an all versions compiled, but at runtime a global
variable chooses each time which piece of code to execute
[advanges: simple;
disadvantages: confuses FCHECK; requires global variable at
runtime; takes a lot more memory at runtime; takes some more
time to execute each time; compilation takes much longer since
it has to compile everything for every machine every time]
(2) The same except using macros to select which body of code to compile
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: still requires versions of source for all systems
around when compiling for any system, thus taking longer to
read it in and slightly longer to select correct version to
compile; requires the macro to know what the target machine
will be, something I'm not sure the cross-compiler maks
available to user macros]
(3) Keep system-dependent stuff in separate files, using funny names
such as SYSDEP-foo as the way the system-dependent stuff is
called from the portable files, keep user-callable function in
portable source files with link to SYSDEP-foo function, and with
comments indicating where the SYSDEP-foo function might be found
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: (a) if functions used as linkage, slightly more
CPU time (b) if macros used as linkage, you won't be able to
TRace system functions by their usual name at runtime unless the
TRace package is smart enough to map (TRace OPEN) into (TRace
SYSDEP-OPEN) for example.]
(4) Same except have user call the system-dependent functions
directly, i.e. they have advertised names rather than funny
names via vector from advertised names
[advantages: minimum runtime memory; minimum runtime CPU time;
disadvantages: confusing to maintainers since they have no idea
whether a function is in portable files or in some random
system dependent file]
-------
∂21-Nov-84 1111 GJC@MIT-MC left to right order of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 11:11:05 PST
Date: 21 November 1984 14:11-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: left to right order of evaluation
To: common-lisp @ SU-AI
Or, "is funcall really considered harmfull?"
Q:
; given:
(defun f ()
(fset 'g #'h)
(prog1 (g (i))
(fset 'g #'h)))
(defun h (ignored)
"left to right is strict")
(defun i ()
(fset 'g #'(lambda (ignored) "left to right is violated")))
; Is (F) => "left to right is strict"
; or => "left to right is violated"
The question is, does common-lisp define the result of (F) in
this case?
This is related to the question of the equivalence of
(G ...) and (FUNCALL (PROGN #'G) ...)
where I add the PROGN to indicate that I don't want compiler
optimization to determine this.
I've observed that on some machines this equivalence is
rather designed in, that a call of a function and a FUNCALL
are exactly the same instruction sequence, but on some
machines they are very different.
-gjc
∂21-Nov-84 1119 KMP@MIT-MC Stability?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 11:19:13 PST
Date: 21 November 1984 14:19-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Stability?
To: Wholey @ CMU-CS-C
cc: Common-Lisp @ SU-AI
In-reply-to: Msg of Tue 13 Nov 1984 00:22 EST from Skef Wholey <Wholey at CMU-CS-C.ARPA>
Date: Tue, 13 Nov 1984 00:22 EST
From: Skef Wholey <Wholey at CMU-CS-C.ARPA>
It seems that if X is implemented as specified, but X is subject to debate,
then the specification of X should not change. Some people are making
appeals to taste, but there are other less tasteful features of the
language that no one's trying to change.
The issue of THROW using EQ or EQL is a discussion of what happens in the
undefined case of using a number or character. EQ and EQL are the same over
the defined range of args, and whether the words are explicit here or not,
the clear implication is one of "is an error", and we have left "is an error"
things open to discussion.
Should CMU and DEC and Data General and Symbolics and whoever else
out there be forced to reimplement something because it's not as
tasteful (in someone's opinion -- not everyone's) as could be?
No one has ever been forced in these discussions to do a particular thing.
The point of putting thoughts on the floor is to find out what consensus is.
I actually believe it is critical that we re-examine certain issues in the
aluminum issue, with the aim of changing them in later editions, even if such
editions don't come soon. Not every decision made in the first edition was
the right decision, and we cannot force users to live with all mistakes
forever. A major purpose of any further discussions on this list must be to
figure out where we've made mistakes and what subset of those it would be
possible/appropriate to correct.
Sure, the compiler could easily figure out where an EQ-Throw could be used.
I'll go and fix our implementation if everyone thinks I should. But
that's not my idea of a stable language specification.
Why not. No working program will break? Formerly undefined programs will
become well-defined. There is nothing even remotely unstable about such a
change. All changes should be so stable!
Hey, why not have Throw take a keyword argument for the test to use? Or an
abitrary predicate that the tag must satisfy? Other keyword arguments
would be useful as well...
(unless (throw *zinger* 'hi! :test #'equalp :if-does-not-exist nil)
(format t "Catch tag ~S was not found.~%" *zinger*))
I actually had what I think was a reasonable application for a :TEST arg
recently. If you're being serious, I'll be glad to explain why it would
be useful. This, by the way, is also a "stable", upward compatible change.
I also like the :IF-DOES-NOT-EXIST key, actually. In Maclisp, I have seen
a few applications for (LET ((ERRSET NIL)) (ERRSET (*THROW ...) NIL)),
which accomplishes the same end. It saves having to do
(DEFVAR *FOO-TAG-AVAILABLE* NIL)
(DEFUN F ()
(*CATCH 'FOO
(LET ((*FOO-TAG-AVAILABLE* T))
...)))
(DEFUN G () (IF *FOO-TAG-AVAILABLE* (*THROW 'FOO *SOMETHING*)))
which just wastes a lot of verbiage. Its only problem comes in a breakpoint
where you might want to bind *FOO-TAG-AVAILABLE* to NIL, but you can't.
There would have to also be an accompanying way for breakpoints to hide
pending catch tags.
-kmp
∂21-Nov-84 1228 JAR@MIT-MC left to right order of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 12:28:13 PST
Date: 21 November 1984 15:27-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject: left to right order of evaluation
To: GJC @ MIT-MC
cc: common-lisp @ SU-AI
In-reply-to: Msg of 21 Nov 1984 14:11-EST from George J. Carrette <GJC>
Date: 21 November 1984 14:11-EST
From: George J. Carrette <GJC>
; Is (F) => "left to right is strict"
; or => "left to right is violated"
The question is, does common-lisp define the result of (F) in
this case?
I remember once looking in the CL manual for a definition of argument
evaluation order, and not finding any. (My apologies if I am ignorant
of some previous discussion of this.)
Options:
(a) It was left undefined and was meant to be left undefined (perhaps
because there was no agreement as to whether or not to define it!).
(b) It was defined to be left-to-right, or it was meant to be
defined and if the manual doesn't say so it was an oversight.
In case (a), I think that, because (probably) all implementations are
left-to-right, if any CL implementation actually came along which was
not left-to-right, 70% of real CL programs would fail to work, bombing
out in very obscure ways. I don't think that users will be able to
restrain themselves from depending on evaluation order unless either
their compiler generates argument-interaction warnings like RABBIT does,
or they are forced to deal with non-left-to-right implementations, or
both.
In case (b), there's the problem GJC brings up. The consistent thing
would be to do the function position before anything else, but
implementors will probably complain that that will slow everything down
(which is true). Inconsistent things to do would be to compute the
function last, or to leave the time at which the function is computed
undefined (as in Maclisp - first in interpreted code, last in compiled).
Either of these would be pretty bizarre, in my opinion, given that
arguments are evaluated left-to-right. But I suspect one or the other
such bizarre behavior is what many CL implementations out there exhibit.
(Certainly if CL is left-to-right then E1 would have to be evaluated
before E2 in (FUNCALL E1 E2); if CL has the first "bizarre" behavior as
described in previous paragraph, then a compiler must not rewrite
(FUNCALL #'G (I)) as (G (I)) unless it can prove that calling I will
not assign #'G.)
So we have a problem either way.
∂21-Nov-84 1244 FAHLMAN@CMU-CS-C.ARPA left to right order of evaluation
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 12:43:53 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 15:42:13-EST
Date: Wed, 21 Nov 1984 15:42 EST
Message-ID: <FAHLMAN.12065403713.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: left to right order of evaluation
In-reply-to: Msg of 21 Nov 1984 14:11-EST from George J. Carrette <GJC at MIT-MC>
If I understand your question (not easy, since you use things like FSET
that are not defined in Common Lisp), you are asking whether, in a
normal function call like "(g (foo))", the mapping from the symbol G to
its definition occurs before or after the call to FOO, which might
change the definition of G as a side-effect.
I don't think that the manual currently addresses this issue.
I would advocate leaving this decision to the implementor, since I know
of at least one implementation that would be badly screwed if either
decision were mandated. Put another way, I'm proposing that it "is an
error" in portable code to change the definition of a symbol while
computing the arguments in a normal call to that symbol, and the results
will be unpredictable if you do this. I suppose the "right" thing is to
do the SYMBOL-FUNCTION of G before computing the args, but specifying
this would limit the flexibility available to the implementor in a place
where tricks can buy you a LOT.
The funcall case is different, I think. In something like "(funcall #'g
(foo))", the translation of the symbol G to a function object clearly
occurs when (function 'G) is evaluated, and nothing that FOO does to G
(short of destructively modifying its definition) can alter that after
the fact.
-- Scott
∂21-Nov-84 1256 @MIT-MC:BROOKS@MIT-OZ Re: left to right order of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 12:56:20 PST
Date: Wed 21 Nov 84 15:52:49-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: left to right order of evaluation
To: JAR@MIT-MC
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from "Jonathan A Rees <JAR @ MIT-MC>" of Wed 21 Nov 84 15:27:00-EST
I think JAR is correct that there is no explicit mention of left to right
order of evaluation in the CL manual. However on page 99 of the
aluminum edition there are the following two paragraphs:
"In generalized-variable references such as shift, incf, push and
setf of ldb, the generalized variables are both read and written
in the same reference. Preserving the source program order of
evaluation and the number of evaluations is particularly important.
As an example of these semantic rules, in the generalized-variable
reference (setf reference value) the value must be evaluated
@i(after) all the subforms of the reference because the value form
appears to the right of them."
And then on page 102 in discussing defsetf there is a sentence:
"The implementation of defsetf takes care of ensuring that subforms
of the reference are evaluated exactly once and in the proper
left-to-right order."
So if the official position is that order is not defined then the above
pieces of the manual are bogus.
Is there any rational reason not to insist on left to right evaluation?
(Note that LET insists (page 110) on evaluating the value forms which
the variables get bound to left to right, so any optimiztion and side
effect mechanisms analysis stuff already needs to be built to make
let super efficient.)
-------
∂21-Nov-84 1309 FAHLMAN@CMU-CS-C.ARPA left to right order of evaluation
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 13:09:38 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 21 Nov 84 16:07:55-EST
Date: Wed, 21 Nov 1984 16:07 EST
Message-ID: <FAHLMAN.12065408362.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: left to right order of evaluation
In-reply-to: Msg of 21 Nov 1984 15:52-EST from Rodney A. Brooks <BROOKS%MIT-OZ at MIT-MC.ARPA>
I believe that the first full paragraph on page 61 of the aluminum
edition specifies left-to-right evaluation of arguments for all function
calls. Or at least, that's the way I read it. I feel certain that it
was everyone's intention that arguments in a normal function call should
be evaluated left-to-right, but I don't recall any discussion of when to
do the symbol-to-function mapping.
-- Scott
∂21-Nov-84 1324 @MIT-MC:BROOKS@MIT-OZ Re: left to right order of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 13:24:43 PST
Date: Wed 21 Nov 84 16:22:25-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: left to right order of evaluation
To: Fahlman@CMU-CS-C.ARPA
cc: common-lisp@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Wed 21 Nov 84 16:11:09-EST
I don't think the paragraph on page 61 specifies order of evaluation
of argument forms. It is talking about application of a function, not
evaluating arguments to which a function will get applied. From the
third paragraph on page 61 it seems clear that ``processed'' does
not include evaluation of argument forms as it talks about intermingling
binding of variables and ``processing''.
The bottom of page 58 and top of 59 seem to be the place to specify
order of evaluation and there there is no mention of order of
evaluation. There should be something explicit there even if it is to
say the order is undefined.
I think the right thing is left to right evaluation of argument forms
and mute on when the symbol-to-function mapping happens. No readable code
could rely on either order for the latter.
(Gee, wouldn't it be fun to be a lawyer...)
-------
∂21-Nov-84 1526 masinter.pa@Xerox.ARPA Re: left to right order of evaluation
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 15:24:20 PST
Received: from Semillon.ms by ArpaGateway.ms ; 21 NOV 84 15:24:44 PST
Date: 21 Nov 84 15:22 PST
From: masinter.pa@XEROX.ARPA
Subject: Re: left to right order of evaluation
In-reply-to: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>'s message of
Wed, 21 Nov 84 15:52:49 EST
To: common-lisp@SU-AI.ARPA
I believe that any portable Lisp needs to have a well defined order of
evaluation for the whole language, including specifying when the
symbol-to-function mapping happens.
∂21-Nov-84 2306 GJC@MIT-MC global function namespace given too much weight perhaps?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 23:06:01 PST
Date: 22 November 1984 02:06-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: global function namespace given too much weight perhaps?
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
In-reply-to: Msg of Wed 21 Nov 1984 15:42 EST from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Please excuse my use of an old name for the concept,
(defun fset (a b) (setf (symbol-function a) b))
It was a good thing I didn't use FSETQ, i.e.
(defmacro FSETQ (A B) `(SETF #',A ,B))
Which brings up a question, is FSETQ as it is defined here
supposed to work in common-lisp?
∂22-Nov-84 1013 FAHLMAN@CMU-CS-C.ARPA global function namespace given too much weight perhaps?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Nov 84 10:13:25 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 22 Nov 84 13:12:13-EST
Date: Thu, 22 Nov 1984 13:12 EST
Message-ID: <FAHLMAN.12065638570.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: global function namespace given too much weight perhaps?
In-reply-to: Msg of 22 Nov 1984 02:06-EST from George J. Carrette <GJC at MIT-MC>
No, FUNCTION is not one of the forms for which SETF is supposed to work.
SYMBOL-FUNCTION is, however.
-- Scott
∂22-Nov-84 1449 GJC@MIT-MC global function namespace given too much weight perhaps?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Nov 84 14:49:32 PST
Date: 22 November 1984 17:50-EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: global function namespace given too much weight perhaps?
To: Fahlman @ CMU-CS-C
cc: common-lisp @ SU-AI
In-reply-to: Msg of Thu 22 Nov 1984 13:12 EST from Scott E. Fahlman <Fahlman at CMU-CS-C.ARPA>
Seems there is a hole here, or at least a gratiutious inconsistency,
in that there is a (call it) variable namespace binding construct,
LET, and a cooresponding side-effect construction, SETQ, and there
is a function namespace binding construct, FLET, but the side-effect
construction FSETQ (if you will) is missing.
Given that it is missing, can we give a reasonable justification for
that, or can we fix the inconsistency?
∂22-Nov-84 1546 JonL.pa@Xerox.ARPA Re: left to right order of evaluation
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 22 Nov 84 15:46:25 PST
Received: from Cabernet.MS by ArpaGateway.ms ; 22 NOV 84 15:45:36 PST
Date: 22 Nov 84 15:43 PST
From: JonL.pa@XEROX.ARPA
Subject: Re: left to right order of evaluation
In-reply-to: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>'s message of
Wed, 21 Nov 84 16:07 EST
To: Fahlman@CMU-CS-C.ARPA
cc: BROOKS%MIT-OZ@MIT-MC.ARPA, common-lisp@SU-AI.ARPA
Yes, there is a slight misnomer in the discussion -- it is, as you
mention in your previous note, relevant only to whether "to do the
SYMBOL-FUNCTION of G before computing the args" or not. The question of
left-to-right order for argument evaluation wasn't ever, as far as I can
recall, seriously questioned.
Two items may influence the pertinent point however:
1) Interpreters classically "snoop" at the function position first,
regardless of whether they are classical Lisp interpreters, or the
"mindless uniformity" style so favored by functional programming
types. Thus, without extra forethought, interpreter would probably
do the SYMBOL-FUNCTION before doing the args; in fact, without the
severe limitation on "special forms" in CL , it would be possible
in other dialects to change even the EXPR/FEXPR decision on the
"function" after beginning the argument evaluations.
2) As you mention, there is some variability here in compile-time
environments; back at the beginning of the VAX/NIL project, we
opted for a design that would "open up" a function call frame on
the stack before actually evaluating the arguments; the format of
the compiled code was to "push" into this opened-up frame, rather
than merely "push"ing at the stack tip. This permitted an error
for "undefined function" to be signalled before the "arguments"
were computed (with potentially many side-effects); it also enabled
more debugging information to be obtained from the stack frame
during the interval of time of evaluating the arguments.
Point 2 was a bit controversial; especially in view of the LispMachine
pattern which was simply to push at the stack tip, and *after* all
arguments were pushed, then decide what to do about a function call.
One area of concern was performance, and the follow should explain why
this decision, *for the VAX* was not a performance impact.
Since the VAX has an very flexible set of instructions, with plenty of
registers to be "frame pointers", this decision caused no slowdown in
the compiled code, but rather cost only an extra byte or two per operand
pushed. The VAX PUSHL opcode, oddly enough, isn't particularly fast --
Rich Bryan and I once reported this odd observation to a mail list
(forget which one, maybe NIL@MC), but others, notably Fateman, had
reported the same finding earlier. To no one's surprise, the VAX CALLS
instruction is the big loser here and I've heard rumors that the DEC
Common Lisp folks have, upon "second system re-design", dropped it
altogether in favor of JSB for Lisp function calling.
As you may infer, I rather favor the doing of the SYMBOL-FUNCTION first,
not only because of the extra debugging information that this way may
supply, but also because it tends to lessen the conflict engendered by
the "separate function cell" which so antagonizes the functional
programming types. However, like you, I would place "performance" at a
priority higher than that for this particular matter of uniformity.
-- JonL --
∂22-Nov-84 2059 FAHLMAN@CMU-CS-C.ARPA global function namespace given too much weight perhaps?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Nov 84 20:59:07 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Thu 22 Nov 84 23:57:55-EST
Date: Thu, 22 Nov 1984 23:57 EST
Message-ID: <FAHLMAN.12065756115.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "George J. Carrette" <GJC@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA
Subject: global function namespace given too much weight perhaps?
The justification is that (after some debate), we decided not to try to
make the function name space parallel to the variable name space in all
respects. These two name spaces do rather different things, and we
decided not to put in all the things that would be needed to make the
two spaces truly parallel. For example, in addition to the
SETQ-equivalent, we left out functional variables in argument lists.
Whether this is a reasonable justification I leave up to you, but that's
how it happened. The inconsistency, if any, is that we let FLET and
LABELS sneak back into the language because a few people thought they
would be useful.
-- Scott
∂23-Nov-84 0339 REM%IMSSS.#Pup@SU-SCORE.ARPA (EQ ...) untrue for numbers?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 03:39:27 PST
Received: from IMSSS by Score with Pup; Fri 23 Nov 84 03:38:06-PST
Date: 23 Nov 1984 0334-PST
From: Rem@IMSSS
Subject: (EQ ...) untrue for numbers?
To: COMMON-LISP%SU-AI@SCORE
Somebody made the claim that (DEFUN TST (Z) (LET ((X Z) (Y Z)) (EQ X Y)))
could in MacLISP sometimes return NIL if given a numeric argument, but I
forgot who it was. I tried it using PLISP (one-segment full-bibop MacLISP)
at SU-AI under the claimed conditions and was unable to get anything
except T to return. I have a transcript to show that person. Would the
person please identify self?
-------
∂23-Nov-84 1407 JAR@MIT-MC left to right order of evaluation
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 14:07:14 PST
Date: 23 November 1984 17:07-EST
From: Jonathan A Rees <JAR @ MIT-MC>
Subject: left to right order of evaluation
To: BROOKS @ MIT-OZ
cc: common-lisp @ SU-AI
In-reply-to: Msg of Wed 21 Nov 84 15:52:49-EST from Rodney A. Brooks <BROOKS%MIT-OZ at MIT-MC.ARPA>
Date: Wed 21 Nov 84 15:52:49-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ at MIT-MC.ARPA>
Is there any rational reason not to insist on left to right evaluation?
[People not interested in the answer to this question need read no further.]
I'll give you the reasons I can think of, and leave it to you to
determine their rationality.
1. There must be, since so many carefully designed languages (e.g.
BLISS, Algol 68, Scheme) and others as well (C, Pascal??, Modula??) make
a point of defining argument evaluation order to be indeterminate.
2. Defining the order of argument evalutation only encourages users to
write programs that make use of a particular order. In the view of
certain pedagogues, such dependence is a stylistically horrible thing
which should be discouraged by the language design. (In the view of
others, of course, it's just fine.)
3. While I agree that a compiler can do a lot in the way of detecting
cases where code motion is permissible, indeterminate order permits code
optimizations which no amount of compile-time analysis can prove
correct. As a simple example, consider
(BAR *X* (FOO))
Assume a machine model in which the two arguments are to be put in
registers A and B, and the return value from calls to unknown functions
comes back in A. Left-to-right code for this would look like
MOVE *X*,TEMP
CALL 0,FOO
MOVE A,B
MOVE TEMP,A
CALL 2,BAR
*X* needs to be saved because the call to FOO, an unknown function,
might clobber it. But better code would result if the call to FOO
happened first:
CALL 0,FOO
MOVE A,B
MOVE *X*,A
CALL 2,BAR
A compiler might like to generate code for the arguments which use the
largest number of registers (the "most complicated" arguments) first, in
order to reduce the amount of data shuffling the object code will have
to do.
4. A particular machine architecture and Lisp implementation might
prefer to evaluate right-to-left, e.g. so that arguments can be pushed
onto a stack properly.
I see now that Common Lisp is decidedly (if not definedly)
left-to-right, and that's probably the politically right thing. Just
for the record, however, I'd like to say that I believe that a portable,
indeterminate order language can be made to work.
∂23-Nov-84 1444 REM%IMSSS.#Pup@SU-SCORE.ARPA Left to right, or parallel, evaluation of arguments to function?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 14:44:30 PST
Received: from IMSSS by Score with Pup; Fri 23 Nov 84 14:43:10-PST
Date: 23 Nov 1984 1441-PST
From: Rem@IMSSS
Subject: Left to right, or parallel, evaluation of arguments to function?
To: COMMON-LISP%SU-AI@SCORE
(If you want to reply but your host doesn't know how to reach
REM@SU-SCORE, try REM%IMSSS@SCORE or if that doesn't work from your
host then REM@MIT-MC. I eagerly await namedomains&servers which
should alleviate this problem.)
Date: Wed, 21 Nov 1984 15:42 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Subject: left to right order of evaluation
If I understand ... question, ... are asking whether, in a
normal function call like "(g (foo))", the mapping from the symbol G to
its definition occurs before or after the call to FOO, which might
change the definition of G as a side-effect.
I don't think that the manual currently addresses this issue.
I would advocate leaving this decision to the implementor,
I would state it a little more strongly. It is generally bad programming
practice for a program to modify itself out from under itself. Most
langauges keep program and data totally separate, even putting program on
readonly pages. Some CPUs carry this further, using different segment
registers for program and data, and having data-manipulation instructions
UNABLE to fetch or store relative to the program base register. In LISP we
can be a little lax, doing things like creating an s-expression and then
passing it to EVAL a moment later, or loading and compiling a program qua
data into memory and then immediately making use of the resultant compiled
functions by calling them qua machine-language subroutines. But note that
although with respect to the whole program we are treating "it" as both
program and data at the same time, we always treat a given sub-form either
as one or another at any given moment, and never (in those examples)
modify a form in place while it is in the midst of being executed. At
worst we execute it completely, then while outside of it we modify it in
preparation for the next execution.
In some extreme cases a macro expander may wish to modify the form to be
faster next time, or a UUO link may be optimized during a call, but the
semantics of the form (except for timing) are the same before an after the
destructive modification.
I therefore propose that we say "IT IS AN ERROR" to attempt to modify any
piece of code (interpreted or compiled) to have different semantics, when
that piece of code is currently in the midst of execution, including
functions which are currently in a half-called state while their arguments
are being recursively evaluated. I'm not sure whether or not we should
explicitly allow any destructive modification which doesn't change
semantics, after all such mod may screw up the PC, causing some parts of
the current evaluation to be skipped or double-executed if data is
compressed or expanded in the vicinity.
Date: Wed, 21 Nov 1984 16:07 EST
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Subject: left to right order of evaluation
I believe that the first full paragraph on page 61 of the aluminum
edition specifies left-to-right evaluation of arguments for all function
calls.
I diasgree. The purpose of the paragraph is to resolve the question of
which dummy arguments match which actual arguments, not the realtime
matter of when the actual arguments are evaluated to yield actual values
which are bound to dummy arguments. It's completely reasonable (to me it
seems) that an implementation would push dotted pairs (dumarg . actarg) on
a stack during resolution of argument matching as described in that
paragraph, but then actually evaluate them in reverse order as they were
popped off the stack and the evaluated results stored in another memory
array-like place (stack, registers, whatever). Note there's no mention of
EVALuating in that paragraph, nor of values, only of PROCESSING of
parameters and arguments, where PROCESSING obviously (to me) means the
matching process and resolution of &REST etc. arguments.
Furthermore, insisting on a particular order of evaluation of arguments in
the general case precludes implementing on a parallel processor such as a
dataflow machine. It would be a royal pain to completely rewrite a
program to replace nearly every function call in the whole program by an
equivalent parallel-evaluation function call, whereas it would be not too
bad to replace the very few places sequential evaluation is really needed
by an explicit sequencial-argument-evaluation macro or special form.
In typical usage, most cases of sequence falls in three classes:
(1) Arguments must be evaluated before calling the function. SCHEME et
al with lazy evaluators which may leave arguments
not-completely-evaluated at the time a function is called present some
problems here, but I think SCHEME simply has to be smart enough to
assure that side-effects are emulated as if arguments had been
evaluated before the function was called.
(2) Explicit sequential forms such as PROG, PROGN, etc. These clearly
must evaluate arguments in the prescribed sequence (or in SCHEME
emulated to have equivalent semantics).
(3) Case resolution forms such as COND. Either they must be evaluated in
the expected order, or side-effects must be emulated as if they did.
The only common errant cases seem to be:
(4) Use of AND or OR to emulate COND, just to save a few parentheses.
(5) Use of LIST to evaluate several forms in sequence and return a list
of their results for visual inspction.
I think AND OR LIST and all other functions should be permitted to
evaluate their arguments in arbitrary order, including in parallel, and
when cases 4 and 5 are needed special forms or macros should be used. Thus
(AND (PAIRP FOO) (EQ (CAR FOO) 'FOO)) would be replaced by
(SEQ-AND (PAIRP FOO) (EQ (CAR FOO) 'FOO)) or something similar, but
(AND (LESSP (LENGTH LIST1) 500) (LESSP (LENGTH LIST2) 700)) could be run
in parallel on some machines.
I would like to see Common-LISP take the bold step of PERMITTING the
effective use of dataflow and other parallel-processing machines without
extensive modification of programs.
Date: Wed 21 Nov 84 16:22:25-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: left to right order of evaluation
I don't think the paragraph on page 61 specifies order of evaluation
of argument forms. It is talking about application of a function, not
evaluating arguments to which a function will get applied. From the
third paragraph on page 61 it seems clear that ``processed'' does
not include evaluation of argument forms as it talks about intermingling
binding of variables and ``processing''.
Glad to find somebody agrees with my interpretation of the manual.
The bottom of page 58 and top of 59 seem to be the place to specify
order of evaluation and there there is no mention of order of
evaluation. There should be something explicit there even if it is to
say the order is undefined.
I agree completely. Note in particular it says "the forms 4 and 5 are
evaluated, producing arguments 4 and 5 for the multiplication", not "the
form 4 is evaluated producing 4, and then the form 5 is evaluated
producing 5, which are the arguments for the multiplication". Clearly it's
ambiguous whether they are done in parallel or in sequence.
I think the right thing is left to right evaluation of argument forms
and mute on when the symbol-to-function mapping happens.
Perhaps for the present, although I would still like to see parallel
evaluation of arguments permitted as I described earlier.
[An aside, who's the cretin who picked the font for numbers in the
aluminum edition? Backwards-E is simply garbage. We're implementing a
language for 5*7-matrix and bitmapped displays, not wristwatches using
liquid crystal 7-segment displays, huh? It was a long time perusing the
manual (on other pages where <exist-symbol> wasn't obviously a number)
before I realized they meant the number 3 not some typographic error.]
-------
∂23-Nov-84 1449 REM%IMSSS.#Pup@SU-SCORE.ARPA Being able to get list of pending CATCH tags?
Received: from SU-SCORE.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 14:49:29 PST
Received: from IMSSS by Score with Pup; Fri 23 Nov 84 14:48:11-PST
Date: 23 Nov 1984 1444-PST
From: Rem@IMSSS
Subject: Being able to get list of pending CATCH tags?
To: COMMON-LISP%SU-AI@SCORE
Date: 21 November 1984 14:19-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: Stability?
Sure, the compiler could easily figure out where an EQ-Throw could
be used. I'll go and fix our implementation if everyone thinks I
should. But that's not my idea of a stable language
specification.
Why not. No working program will break? Formerly undefined programs will
become well-defined. There is nothing even remotely unstable about such a
change. All changes should be so stable!
Hey, you're thinking only about the users on a system with perfect
implementators who can keep up with all the changes without breaking
anything, not the poor implementators who must be so perfect. More than
likely, after each incompatible change in the spec there'll be a period of
years when not all implementations have caught up. If changes occur more
often than that, users will never obtain a working up-to-date
implementation, and thus despite a common latest-standard at any moment
there will be no implementations satisfying any common standard. I think
your above statement should be watered down considerably.
Hey, why not have Throw take a keyword argument for the test to
use?
This reminds me of a serious deficiency in USLISP and PSL and I think
Common-LISP too. There's no way for the user in a break loop to get a
listing of pending CATCH tags and thus have some idea which one to throw
to in order to unwind cleanly from a system-detected error. For example,
catch tags in a database update application might include NORMAL-RETURN
and ABORT-CATCH, where the latter would enter a menu that offers unwinding
the update or closing files in their present state or rolling back to a
checkpoint. The poor user might not have time to search the documentation
to find the name of the catch tag. Surely being able to ask
(PENDING-CATCH-TAGS) from the break package would be useful. I propose
Common LISP include such a way of getting a list of currently pending
catch tags by evaluation of some form like that.
Please correct me if CL already provides this facility.
-------
∂23-Nov-84 1519 RPG List of pending catch tags
To: rem@IMSSS, common-lisp@SU-AI.ARPA
Despite what many people believe, the Common Lisp designers have left
some programs out of the Common Lisp spec, so you, the user, can have
some fun too and write your own. If you're interested in maintaining
a list of pending catch tags, write it yourself with a special, called
something like *PENDING-TAGS*. Then you can write:
(defmacro memo-catch (tag form)
`(let ((*pending-tags* *pending-tags*)
(tag ,tag))
(push tag *pending-tags*)
(catch tag ,form)))
-rpg-
∂23-Nov-84 1548 KMP@MIT-MC memo-catch
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 15:47:58 PST
Date: 23 November 1984 18:48-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: memo-catch
To: rpg @ SU-AI
cc: common-lisp @ SU-AI
Actually, you'd want to bind the tag list AFTER you enter the catch
frame, but I agree it can be done. eg,
(defmacro memo-catch (tag &body forms)
(let ((g (gentemp)))
`(let ((,g ,tag))
(*catch ,g
(let ((*pending-tags* (cons ,g *pending-tags*)))
,@forms)))))
However, I assume REM's comment was for the sake of debugging, since it
might be helpful interactively in determining how to proceed a broken
program that had been written with ordinary primitives.
For what it's worth, a common argument against your MEMO-CATCH solution
goes something like: ``If I'd known that was the catch I needed to
memoize, I wouldn't have had to memoize it!''
-kmp
∂23-Nov-84 1752 REM@IMSSS access to list of pending CATCH tags?
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 84-11-23 17:47:20 PST (=GMT-8hr)
Date: 84-11-23 17:45:04 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A131714014450.G0398
From: Robert Elton Maas <REM@SU-IMSSS.?>
To: COMMON-LISP@SU-AI
Subject: access to list of pending CATCH tags?
Reply-to: "REM%IMSSS"@SU-SCORE.ARPA
Date: 23 Nov 84 1519 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
Subject: List of pending catch tags
Despite what many people believe, the Common Lisp designers have left
some programs out of the Common Lisp spec, so you, the user, can have
some fun too and write your own.
That's rather hard to believe given the plethoria of functions I've
never in my life used such as: ASINH ACOSH ATANH ... STRING-RIGHT-TRIM ...
With all those rarely-used functions as REQUIRED functions in any CL
implementation, it's hard to believe a basic debugging need like seeing
which catch tags are pending has been left for the programmer to
invent himself. More likely it was an oversight or poor design decision.
Date: 23 November 1984 18:48-EST
From: Kent M Pitman <KMP @ MIT-MC>
Subject: memo-catch
...
However, I assume REM's comment was for the sake of debugging, since it
might be helpful interactively in determining how to proceed a broken
program that had been written with ordinary primitives.
I admit my example of database application was answered by the
MEMO-CATCH above, but indeed my original idea was more for debugging
as KMP guessed correctly. Perhaps there should be two levels, a way of
getting pending catch tags that you can *always* get from program code
inside a pending catch, such as I requested an KMP concurs, for
debugging; and an explicit user-level facility such as MEMO-CATCH. But
MEMO-CATCH really should provide not just the list of tags, but also
user-level documentation for each, such as "if you use this catch tag
you'll lose all your database updates since the first of the preceding
month" and "if you use this catch tag you'll not lose any updates but
a wizard will have to patch the database back together before it can
be used again" etc. Thus I'd like the built-in CATCH to provide a
crude level of tags for the sake of debugging and graceful recovery
from gross bugs during debugging, and the user can provide an
elaborate mechanism for end-users.
For what it's worth, a common argument against your MEMO-CATCH solution
goes something like: ``If I'd known that was the catch I needed to
memoize, I wouldn't have had to memoize it!''
Yup, I agree. If you need it for debugging, it should be there always
(or at least by default during debugging) instead of requiring an
explicit action each time to install it. That's the whole idea of
the LISP interprtor, if you leave things out by mistake the
debug-runtime environment has enough info around that you can diagnose
the problem from inside the error without having to modify your source
and recompile and/or reload.
∂23-Nov-84 2008 FAHLMAN@CMU-CS-C.ARPA Being able to get list of pending CATCH tags?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 20:08:43 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 23 Nov 84 23:07:33-EST
Date: Fri, 23 Nov 1984 23:07 EST
Message-ID: <FAHLMAN.12066009089.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem@MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Being able to get list of pending CATCH tags?
In-reply-to: Msg of 23 Nov 1984 17:44-EST from Rem at IMSSS
I think that a PENDING-CATCH-TAGS function sounds pretty useful for
debugging. It would be easy (for the implementors) to do in all the
implementations I know about. I think it might be worthwhile for us to
add this to our own implementaiton, though I am not sure it is worth
putting into the white pages. Since low-level debugging stuff is
inherently unportable, there's no compelling reason to add this function
to the white pages. Note that BACKTRACE (or BAKTRACE, for you Maclisp
fans) is not there either, though every self-respecting implementation
will provide some way to examine the stack.
-- Scott
∂23-Nov-84 2033 FAHLMAN@CMU-CS-C.ARPA Left to right, or parallel, evaluation of arguments to function?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 20:25:45 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Fri 23 Nov 84 23:24:34-EST
Date: Fri, 23 Nov 1984 23:24 EST
Message-ID: <FAHLMAN.12066012187.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Rem@MIT-MC.ARPA
Cc: COMMON-LISP@SU-AI.ARPA
Subject: Left to right, or parallel, evaluation of arguments to function?
In-reply-to: Msg of 23 Nov 1984 17:41-EST from Rem at IMSSS
Evaluation of arguments is definitely intended to be left-to-right. The
only argument is about whether the manual actually comes out and says
this (I think it does) or whether it just hints at this. In the latter
case, the omission is just an oversight.
It is not a goal of Common Lisp to be a good language for dataflow or
other statement-level parallel architectures. There's no clear
consensus on what the right set of features for a dataflow language
would be, but Common Lisp, even if we loosened up the rules on argument
evaluation, would not be the right thing. It seems silly to include
some feature just because it makes Common Lisp slightly less bad at
doing something it is not intended to do anyway, so we went with Lisp
tradition in requiring left-to-right evaluation.
-- Scott
∂25-Nov-84 1216 RPG Re: Left to right, or parallel, evaluation of arguments to function?
∂23-Nov-84 2125 @MIT-MC:BROOKS@MIT-OZ Re: Left to right, or parallel, evaluation of arguments to function?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 21:21:36 PST
Date: Sat 24 Nov 84 00:21:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Left to right, or parallel, evaluation of arguments to function?
To: Fahlman@CMU-CS-C.ARPA
cc: rpg@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Fri 23 Nov 84 23:34:49-EST
I'll save the whole Common-Lisp list this message and just relate
a recent experience to you.
I don't think it is clear to everyone that the manual says left to
right evaluation of arguments is required of CL. I have written a book
"Programming in Common Lisp" and last week while out at LUCID, Eric
Benson was giving me some comments on the manuscript. He objected to
an example that relied on left to right (not, I might add, advocating
it as sound programming style, but using it to illustrate some issues
with side effects), on the grounds that CL does not require left to
right. We then combed the manual and rejected the page 61 paragraph as
not declaring left to right is required. LUCID was left in the belief
that indeed left to right is not required (making a whole lot of
already implemented side effects analysis in the compiler
unnecessary...) in CL. So I really think the next version of the
manual should say left to right explicitly. If even implementors such
as LUCID can't divine from the manual that it is required then it
clearly needs to be said more explicitly.
Now the real question: who's in charge of the manual these days
(perhaps this was decided at Monterrey but I wasn't there and don't
know)?
-------
∂25-Nov-84 1217 RPG Left to right, or parallel, evaluation of arguments to function?
∂23-Nov-84 2340 FAHLMAN@CMU-CS-C.ARPA Left to right, or parallel, evaluation of arguments to function?
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 23:40:15 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Sat 24 Nov 84 02:39:04-EST
Date: Sat, 24 Nov 1984 02:39 EST
Message-ID: <FAHLMAN.12066047590.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: "Rodney A. Brooks" <BROOKS%MIT-OZ@MIT-MC.ARPA>
Cc: rpg@SU-AI.ARPA
Subject: Left to right, or parallel, evaluation of arguments to function?
In-reply-to: Msg of 24 Nov 1984 00:21-EST from Rodney A. Brooks <BROOKS%MIT-OZ at MIT-MC.ARPA>
OK, I guess it really isn't clear.
RPG is gathering all this stuff into a file, and presumably in six
months or so Guy will find the time and energy to harvest the changes on
which there has been no disagreement and put them into the second
edition. He may actually do this by himself, since a second edition
would sell a bunch of additional copies of the book; if not, one of us
will have to ghost-write the changes for him.
On the issues that are not mere clarifications or on which there is some
serious difference of opinion, we will have to go through a cycle of
proposal, argument, recommendation, and voting. Judging by our past
experiences, someone other than Guy will have to carry the ball on this
nasty stuff, since it is the canonical thankless job and Guy isn't much
into that.
Is this book of yours a tutorial? Sounds useful. It might be wise to
have someone outside of Lucid take a look at it if it goes into taste
and efficiency issues, just to get some alternative viewpoints on these
things.
-- Scott
∂26-Nov-84 0848 RPG Re: Left to right, or parallel, evaluation of arguments to function?
∂23-Nov-84 2125 @MIT-MC:BROOKS@MIT-OZ Re: Left to right, or parallel, evaluation of arguments to function?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 23 Nov 84 21:21:36 PST
Date: Sat 24 Nov 84 00:21:51-EST
From: Rodney A. Brooks <BROOKS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Left to right, or parallel, evaluation of arguments to function?
To: Fahlman@CMU-CS-C.ARPA
cc: rpg@SU-AI.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Fri 23 Nov 84 23:34:49-EST
I'll save the whole Common-Lisp list this message and just relate
a recent experience to you.
I don't think it is clear to everyone that the manual says left to
right evaluation of arguments is required of CL. I have written a book
"Programming in Common Lisp" and last week while out at LUCID, Eric
Benson was giving me some comments on the manuscript. He objected to
an example that relied on left to right (not, I might add, advocating
it as sound programming style, but using it to illustrate some issues
with side effects), on the grounds that CL does not require left to
right. We then combed the manual and rejected the page 61 paragraph as
not declaring left to right is required. LUCID was left in the belief
that indeed left to right is not required (making a whole lot of
already implemented side effects analysis in the compiler
unnecessary...) in CL. So I really think the next version of the
manual should say left to right explicitly. If even implementors such
as LUCID can't divine from the manual that it is required then it
clearly needs to be said more explicitly.
Now the real question: who's in charge of the manual these days
(perhaps this was decided at Monterrey but I wasn't there and don't
know)?
-------
∂26-Nov-84 0854 RPG Please add...
∂21-Nov-84 1626 @MIT-MC:smh@MIT-EMS Please add...
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Nov 84 16:26:28 PST
Date: 21 Nov 1984 19:12:44-EST
From: smh@mit-ems@mit-mc
To: common-lisp-request@su-ai
Subject: Please add...
Greetings. For some time I have been the de facto maintainer of the
various MIT compatibility packages running under Franz Lisp, and in
particular, the flavor package. The denizens of Franz Inc and I have
recently been considering an effort to upgrade this code. It is
obviously necessary to track common lisp developments.
I need to be added to these Common Lisp mailing lists:
COMMON-LISP-FORUM
COMMON-LISP-IMPLEMENTATION
and particularly:
CL-OBJECT-ORIENTED-PROGRAMMING
So far as I know, the first two are redistributed locally by MIT-MC,
but it appears the third is not. If you prefer, I could obtain
the local distribution for the first two. Please advise. Also,
where is CL-OBJECT-ORIENTED-PROGRAMMING archived?
Thanks.
Steve Haflich
MIT Experimental Music Studio
smh@mit-ems@mit-mc
Mailing Lists
I've added you to all three. I presume you get the normal Common Lisp
mailing list via re-distribution?
The archive is CLOBOR.MSG[COM,LSP] at SU-AI. No login or password required to
FTP it away.
∂26-Nov-84 0955 J.Dalton%edxa@Ucl-Cs.ARPA Manual does say left to right
Received: from [14.0.0.9] by SU-AI.ARPA with TCP; 26 Nov 84 09:54:36 PST
Received: from edxa.ac.uk by 44d.Ucl-Cs.AC.UK via Janet with NIFTP
id a001884; 26 Nov 84 16:47 GMT
From: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Date: Monday, 26-Nov-84 16:07:40-GMT
Message-ID: <131716-530-041@EDXA>
To: common-lisp <common-lisp%su-ai.arpa@ucl-cs.arpa>,
J.Dalton%edxa@ucl-cs.arpa
Subject: Manual does say left to right
--------
It turns out that The Book *does* explicitly specify that argument
forms are evaluated from left to right; but not, unfortunately, in any
place as obvious as page 61. If you look on page 194, 3rd full
paragraph, you will find:
For functions that are mathematically associative (and
possibly commutative), a Common Lisp implementation may
process the argumants in any manner consistent with assoc-
iative (and possibly commutative) rearrangement. This does
not affect the order in which the argument forms are eval-
uated, of course; that order is always left to right, as in
all Common Lisp function calls. ...
This section is clearly talking about evaluating argument forms as
distinct from processing arguments. Page 61, on the other hand is
talking only about processing arguments. The meaning of page 61 can
be clarified by juxtaposing it with part of page 58:
[p. 58] ... Any and all remaining elements of the list are
forms to be evaluated; one value is obtained from each form,
and these values become the *arguments* to the function. The
function is then *applied* to the arguments. ... [p. 61] When
the function represented by the lambda-expression is applied
to the arguments, the arguemnts and parameters are processed
in order from left to right. ...
(Isn't textual criticism fun? I knew those Comp Lit courses weren't
for nothing. :-))
-- Jeff Dalton
AI Applications Institute
University of Edinburgh
--------
∂26-Nov-84 1508 RPG Ballot
To: quinquevirate@SU-AI.ARPA
∂26-Nov-84 1505 Moon@SCRC-STONY-BROOK.ARPA Ballot
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 26 Nov 84 15:04:48 PST
Received: from SCRC-EUPHRATES by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 132486; Mon 26-Nov-84 15:58:18-EST
Date: Mon, 26 Nov 84 15:56 EST
From: "David A. Moon" <Moon@SCRC-QUABBIN.ARPA>
Subject: Ballot
To: "Daniel L. Weinreb" <DLW@SCRC-QUABBIN.ARPA>
cc: Fahlman@CMU-CS-C.ARPA, rpg@SU-AI.ARPA, steele@TL-20B.ARPA
In-Reply-To: <841126144851.3.DLW@CHICOPEE.SCRC.Symbolics.COM>
Message-ID: <841126155637.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Monday, 26 November 1984, 14:48-EST
From: Daniel L. Weinreb <DLW at SCRC-TENEX>
OK, I will try to take a shot at this. I have forgotten where the
archives of the Common-Lisp mailing list are, however; could someone
fill me in? Thanks.
Locally it's archived in S:>Mail-Archive>Common-Lisp.text. That file
does not by any means go back to the oldest Common Lisp mail, which is
presumably on SU-AI somewhere.
It is in the files:
COMMON.1[COM,LSP]
COMMON.2[COM,LSP]
COMMON.3[COM,LSP]
COMMON.MSG[COM,LSP]
which is chronological order. No login and no password needed to ftp them
away.
∂10-Dec-84 1135 RPG loop & defmacro
∂09-Dec-84 1440 CL.BOYER@UTEXAS-20.ARPA loop & defmacro
Received: from UTEXAS-20.ARPA by SU-AI.ARPA with TCP; 9 Dec 84 14:39:55 PST
Date: Sun, 9 Dec 1984 16:38 CST
From: CL.BOYER@UTEXAS-20.ARPA
To: steele@tartan
Cc: rpg@su-ai, hedrick@rutgers
Subject: loop & defmacro
Since RPG named you as moderator of the "iteration/loop" subgroup
I haven't seen any mail on the subject. Has there been any?
In my opinion, LOOP is pretty good as it is and should be
adopted as part of Common Lisp. If I had my way, I would
add to it something that was subtracted from the Interlisp
I.S.OPR when LOOP was coded, namely the ability to add more
I.S.OPRS. For example, I now write in Zetalisp:
(loop for x in l with ans = 0
do (setq ans (logor x ans))
finally (return ans))
where I would like to write
(loop for x in l logor x).
I used to be able to write something like that in Interlisp,
which has a facility for defining the initial, iterative,
and final action of a new "quantifier" such as logor.
Anyway, that's my 2-bits worth.
Finally, and totally unrelatedly, is it true that
(defmacro foo x ...)
is not permited in Common Lisp and that
I need to write
(defmacro foo (&whole x) ...)?
I'm trying to find some common ground with psl and the maclisp
dialects, but it doesn't look like there is a general
purpose intersection. As I read it, a lambda list has
to be a list, and that excludes a symbolp.
P.S. Hedrick's 2060 Common Lisp permits (defmacro foo x ...).
Thanks,
Bob
∂10-Dec-84 1140 RPG Re: CL the copyright
∂10-Dec-84 0557 OHLANDER@USC-ISI.ARPA Re: CL the copyright
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 10 Dec 84 05:57:46 PST
Date: 10 Dec 1984 08:57-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: CL the copyright
From: Ohlander
To: fateman%ucbdali@UCB-VAX.ARPA
Cc: steele@CMU-CS-C.ARPA, cl-charter@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA]10-Dec-84 08:57:25.OHLANDER>
In-Reply-To: <8412070636.AA26142@ucbdali.ARPA>
Steve Squires and I have talked to Sam Fuller at DEC about this
issue and I think we have closure. After Guy Steele had sent a
letter to John Osborne of Digital Press, Sam Fuller got together
the Digital Press people and also explained the problem. As a
result, there is some tentative agreement that DEC will allow
other companies to reproduce the Common Lisp manual for a
reasonable fee. In addition they won't have to go through all
this format nonsense. It was also agreed that DEC would have
commercial rights while the Common Lisp group maintains rights to
the Common Lisp specification. DEC will also accomodate any
changes in the specification made by the Common Lisp group. This
has yet to be ratified with John Osborne but I don't think there
will be any major difficulty.
Ron Ohlander
∂10-Dec-84 2158 RPG macros qua functions allowed??
∂10-Dec-84 1620 REM@IMSSS macros qua functions allowed??
Sent: to SU-AI.ARPA by IMSSS.? via ETHERNET with PUPFTP; 84-12-10 16:17:34 PST (=GMT-8hr)
Date: 84-12-10 15:09:08 PST (=GMT-8hr)
Message-id: SU-IMSSS.REM.A131735002036.G0398
From: Robert Elton Maas <REM@SU-IMSSS.?>
To:RPG@SU-AI,Moon@SCRC-RIVERSIDE
Subject: macros qua functions allowed??
Reply-to: REM%IMSSS@SU-SCORE.ARPA
Date: 25 Nov 84 1213 PST
From: Dick Gabriel <RPG@SU-AI.ARPA>
I tried the experiment on sail, and it did exactly what Moon said:
Redistributed-date: Mon, 1 Oct 84 14:20 EDT
Redistributed-date: Thu, 27 Sep 84 23:49 EDT
Date: Mon, 24 Sep 84 16:56 EDT
From: Moon@SCRC-RIVERSIDE.ARPA
Date: 23 Sep 1984 1752-PDT
From: Rem@IMSSS
In Common LISP there seems to be a strong dichotomy between functions
(all arguments evaluated before call) and macros&SpecialForms, almost
to the point of forbidding implementors to jump across the barrier. ...
It is impermissible for an implementation to implement something documented
as a function as something other than a function. This doesn't rule out
compiler optimizations, of course, and all the implementations I know about
do compiler optimizations for the hairier and most common functions with
&KEY arguments.
If the purpose of lexical bindings et al is to make interpretor and
compiler have identical semantics, even for incorrect programs
(programs with undeclared free variables), one easy way to do this is
not to implement an interpretor at all, but rather to use an
incremental compiler qua interpretor. But if you're allowed to use
compiler macros in the batch-mode compiler but not in the incremental
compiler qua interpretor, you're up a creek. I think it should be
permissible to use macros in any context whatsoever providing the
semantics are correct, that is the input/output/sideeffect behaviour
of functions should be the same as specified, and FUNCTIONP and MACROP
should magically give the result specified in the manual even if they
have to mask the internal representation to do it. Can you rebut this?
∂11-Dec-84 1323 jrg@cmu-cs-spice.arpa Re: left to right order of evaluation
Received: from CMU-CS-SPICE.ARPA by SU-AI.ARPA with TCP; 11 Dec 84 13:23:19 PST
Date: Tuesday, 11 December 1984 16:18:24 EST
From: Joseph.Ginder@cmu-cs-spice.arpa
To: common-lisp@su-ai.arpa
Subject: Re: left to right order of evaluation
Message-ID: <1984.12.11.21.10.13.Joseph.Ginder@cmu-cs-spice.arpa>
I distinctly remember having a discussion about this at one of the few
Common Lisp meetings (in Pittsburgh?). As I recall, it was decided (with
little debate) that left-to-right order of argument evaluation was adopted.
While the decision regarding this issue in particular does not necessarily
imply strict left-to-right evaluation, this topic arose when someone at the
meeting asked if the default value expressions for optional arguments could
refer to an argument preceding the optional in the formal parameter list (in
left-to-right order, of course). This led to the topic of whether, in
general, left-to-right evaluation order was required. The answer to both
questions, as I recall, was yes.
Rather than depend on my or someone else's memory, did anyone keep notes
of the meetings? I think Guy did.
--Joe
P.S. Not that this recollection solves the problem of deciding whether or
not the decision of the committee was the "right" one or not...... -- if
such matters are open to change. (I hope not.)
∂12-Dec-84 1054 STEELE@TL-20A.ARPA Legalities
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 10:53:58 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Wed 12 Dec 84 13:54:43-EST
Date: Wed 12 Dec 84 13:54:41-EST
From: STEELE@TL-20A.ARPA
Subject: Legalities
To: quinquevirate@SU-AI.ARPA
I have been speaking with John Osborn at Digital Press.
Two issues:
(1) Their lawyers are almost done approving the agreement with
Data General, but are very uptight about getting the whole thing
exactly right. They *may* (only a maybe) decide to ask each of
you whether all this is okay by you. So you may get a letter
of some kind from the lawyers asking you to sign some kind of
statement. I just didn't want it to catch you by surprise if
it happens.
(2) Digital Press would also like to include in contracts with
Common Lisp vendors who reprint the book a clause calling for
some amount of money to be paid to help support maintenance
of the Common Lisp language, for example to underwrite the cost
of future meetings. The only problem is that right now there is
no legal entity to which to pay such funds. They envision that
maybe for each such contract a few hundreds or thousands might
be paid to "The Common Lisp Committee", perhaps to underwrite
travel costs for university types (or maybe everyone) to attend
standardization meetings or maybe to defray the cost of
producing new drafts, etc. What do you all think?
--Guy
-------
∂12-Dec-84 1112 RPG Why Lawyers Make Better Lab Animals than Rats (*)
To: quinquevirate@SU-AI.ARPA
(1) I presume by your statement you mean that Digital Press is afraid
that by making mistakes the contract it cuts with Data General and with
other vendors will be bad or `not right.' And they want to make sure they
make no mistakes. Right? In this case, if they want me to sign off on the
contract, I will will want to see the contract first.
(2) One problem is whether Digital Press and DEC are also contributing
to this fund. Another problem is whether the charter that (I hope) we will
set up will be well-served by being funded in this way by private concerns.
That is, if we are to set up taxation to support the standardization
activities, I want to be sure that the taxation structure is right. Perhaps
we will want the taxation to be related to voting rights, for example.
Digital Press jumping into this issue sounds premature to me: I want
to have the charter set up first.
-rpg-
(*) There are more lawyers than white rats, and researchers don't form
emotional attachments to them.
∂12-Dec-84 1821 FAHLMAN@CMU-CS-C.ARPA Why Lawyers Make Better Lab Animals than Rats (*)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 18:21:02 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 12 Dec 84 21:21:33-EST
Date: Wed, 12 Dec 1984 21:21 EST
Message-ID: <FAHLMAN.12070970510.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Why Lawyers Make Better Lab Animals than Rats (*)
In-reply-to: Msg of 12 Dec 1984 14:12-EST from Dick Gabriel <RPG at SU-AI.ARPA>
My God, Data General is still waiting? That's why we've got to get the
copyright away from Digital Press -- it's not that they won't be
reasonable eventually, it's just that they have no incentive to cut the
red tape. I'll be glad to look over this contract and respond at once,
but I sure hope that it doesn't take 9 months every time someone wants
to do something with the manual.
As for using income from the manual to support standardization efforts,
that's not a bad idea (assuming Digital Press pays their share along
with all the others), but I think we've got enough complexity
surrounding the manual situation right now and the last thing we need is
to mix in another set of issues.
There has been very little feedback on the charter, I've been getting
ready to send out a big message proposing what I think should be done.
The implicit threat that silence will be taken for assent should get the
pot boiling. Basically, I'm going to propose a non-profit corporation
physically located near one of the universities from which it can buy
computer time and Arpanet access. There would be individual members
(low dues) and corporate members. The corporate members would pay
yearly dues of $20K or so. (Maybe a substantial discount for companies
with less than 10 employees...) For that fee they get updates on pooled
software at distribution cost, certification of any implementations they
do at cost, and the right to use the "Certified Common Lisp" trademark
in their ads for certified products, plus the satisfaction of having
done their fair share to support the standardization effort. They also
get some number of individual memberships for their people, and it is
individuals, as individuals, who do the voting.
There's a lot more, but that's the part about funding. My guess is that
10 - 20 companies, at least, would join up, which should keep things
sufficiently well lubricated. Does anyone not believe this? Any
surplus beyond administrative expenses can be used to fund projects to
produce public domain code and documents for the common good, or to
allow the executive committee to meet periodically in exotic locales.
If the organization raises money that way, we wouldn't have to put any
special fees on the book. If this organization held the copyright (with
certain exclusive rights retained by Digital Press), we could decree
that only corporate members of the organization get to reprint the book
without paying a big surcharge.
-- Scott
∂12-Dec-84 1822 FAHLMAN@CMU-CS-C.ARPA Why Lawyers Make Better Lab Animals than Rats (*)
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 18:22:08 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 12 Dec 84 21:22:41-EST
Date: Wed, 12 Dec 1984 21:22 EST
Message-ID: <FAHLMAN.12070970725.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: quinquevirate@SU-AI.ARPA
Subject: Why Lawyers Make Better Lab Animals than Rats (*)
In-reply-to: Msg of 12 Dec 1984 14:12-EST from Dick Gabriel <RPG at SU-AI.ARPA>
* How do you tell the lawyers from the rats?
∂12-Dec-84 2307 GS70@CMU-CS-A.ARPA Re: left to right order of evaluation
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 23:07:26 PST
Date: 13 Dec 84 0202 EST (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
Subject: Re: left to right order of evaluation
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12065408362.BABYL@CMU-CS-C.ARPA>
The first full paragraph on page 61 is discussing the application
of a function to arguments, not the evaluation of argument forms
in a function call. I read this paragraph as dealing with already-evaluated
arguments, saying w
nothing about how the arguments were produced.
I, at least, have understood implicitly that Common Lisp would evaluate
argument forms from left to right, but indeed the manual seems not to
say anything explicit about it directly. The one reason for not
enforcing this order might be to make life easier for certain
multiprocessing implementations by invalidating programs that depend
on such ordering. (In most cases I find it is poor style to depend
critically on the left-to-right argument-evaluation ordering.)
All things considered, however, I do not advocate eliminating this
left-to-right ordering from the language if in fact we are all
agreed that such ordering is now in the language definition.
--Guy
∂12-Dec-84 2346 GS70@CMU-CS-A.ARPA I'm the cretin
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 23:46:36 PST
Date: 13 Dec 84 0219 EST (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: Rem%IMSSS@SU-SCORE.ARPA
Subject: I'm the cretin
CC: common-lisp@SU-AI.ARPA
In-Reply-To: "Rem@IMSSS's message of 23 Nov 84 17:41-EST"
I agree that the code font in the CL manual is terrible. However,
everything else the typesetter had to offer me was worse. We spent
about a month just trying to cobble together pieces of several fonts
that didn't look too terrible together and between them provided the
full printing ASCII character set in a fixed-width form. Commercial
typesetters simply are not used to printing programs; there are very
few good-looking fixed-pitch fonts. Indeed, there are very few fixed-pitch
fonts, and most of them are purposely designed to look "computerish".
Yuck.
--Guy
∂12-Dec-84 2347 GS70@CMU-CS-A.ARPA Re: Manual does say left to right
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 12 Dec 84 23:47:17 PST
Date: 13 Dec 84 0232 EST (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: DALTON FHL (on ERCC DEC-10) <J.Dalton%edxa@ucl-cs.arpa>
Subject: Re: Manual does say left to right
CC: common-lisp@SU-AI.ARPA
In-Reply-To: <131716-530-041@EDXA>
More and more I am reminded of the incident in which Asimov attended
a lecture on the subject of one of his short stories. The lecturer
made several remarks of the form "this part of the story has thus-and-so
purpose" and "clearly the author had X in mind in writing that passage".
Afterward Asimov came up to the lecturer and politely disagreed with
some of these points, suggesting other interpretations. They had a
friendly discussion but the lecturer did not yield, and finally Asimov
played his trump card: "Well, I think I might know what the author
had in mind because I am the author!" The lecturer smiled and said,
"Oh, my goodness, I am very glad to meet you, Dr. Asimov; but tell me:
just because you wrote the story, what makes you think you know
anything about it?"
Well, just because I wrote all the words in the CL manual doesn't mean
I know any more than anyone else about what's in it. I'm sure a good
deal of work remains for careful reviewers, critics, and exegetes.
--Guy
∂13-Dec-84 0657 STEELE@TL-20A.ARPA Rats, etc.
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 13 Dec 84 06:57:30 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Thu 13 Dec 84 09:58:29-EST
Date: Thu 13 Dec 84 09:58:24-EST
From: STEELE@TL-20A.ARPA
Subject: Rats, etc.
To: quinquevirate@SU-AI.ARPA
Well, I'm sure the DEC lawyers are being at least an order or two of
magnitude more paranoid than usual just because it's DG.
Dick implicitly answered Scott's question in his footnote. You take
the rat/lawyer and put it in a lab with a researcher, and if the
researcher becomes emotionally attached to it, then it must be a rat.
(This is only a semi-decision procedure.)
--Guy
-------
∂15-Dec-84 2314 masinter.pa@Xerox.ARPA recruiting
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 15 Dec 84 23:14:24 PST
Received: from Burger.ms by ArpaGateway.ms ; 15 DEC 84 23:10:54 PST
From: masinter.pa@XEROX.ARPA
Date: 15 Dec 84 23:10:43 PST
Subject: recruiting
To: common-lisp@SU-AI.ARPA
I know this is in violation of whatever, but I thought I'd risk it
anyway....
If you didn't know, Xerox is actively recruiting Lisp wizards. If you're
interested in exploring your options, give me a call (415) 494-4365, or
drop a line, or whatever...
∂19-Dec-84 1856 RPG Common Lisp Specification
To: quinquevirate@SU-AI.ARPA
∂19-Dec-84 0935 OHLANDER@USC-ISI.ARPA Common Lisp Specification
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 09:35:30 PST
Date: 19 Dec 1984 12:35-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Common Lisp Specification
From: OHLANDER@USC-ISI.ARPA
To: Squires@USC-ISI.ARPA, Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA, Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]19-Dec-84 12:35:19.OHLANDER>
Gentlemen,
I have just talked with John Osbourne at Digital Press and we
appear to have mutual agreement on rights to the Common Lisp spec.
The Common Lisp User's Group will have rights to the specification.
In turn, the group will give Digital Press commercial printing rights
when published documents are needed. Digital Press will publish
appropriate changes and will also furnish packages to other vendors for
a reasonable licensing fee. John Osbourne has also said that they
may be able to feed some portion of profits back to the User's Group
which would help meet expenses.
Sam Fuller of DEC has suggested that we try to get the User's Group
chartered under the AAAI. I think the idea has merit. What do
you all think?
Ron
P. S. Dick, will you make sure that the other members of the
original five get a copy of this message?
∂19-Dec-84 2250 GS70@CMU-CS-A.ARPA Do I really know anything about Common LISP?
Received: from CMU-CS-A.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 22:50:29 PST
Date: 20 Dec 84 0149 EST (Thursday)
From: Guy.Steele@CMU-CS-A.ARPA
To: common-lisp@SU-AI.ARPA
Subject: Do I really know anything about Common LISP?
In-Reply-To: "Robert Elton Maas's message of 17 Dec 84 00:43-EST"
REM,
On the contrary: I remember explicitly thinking about L-to-R evaluation
several times while writing the book, but somehow the words I intended at
one time to write never appeared in the book.
One can intend all kinds of things, or fail to intend all kinds of things,
but a book that big is so complicated it's all too likely you'll mess upo
somewhere, whether in transcribing other people's ideas or your own.
That's why we have EMACS instead of :COPY TTY:,DSK: (and, for that
matter, DDT as well as MIDAS) [non-MIT people please excuse the lapse
into ITS terminology].
--Guy
∂20-Dec-84 0717 greek@DEC-HUDSON Does anyone understand :REHASH-THRESHOLD?
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 20 Dec 84 07:17:29 PST
Date: Thu, 20 Dec 84 10:11:20 EST
From: greek@DEC-HUDSON
Subject: Does anyone understand :REHASH-THRESHOLD?
To: common-lisp@su-ai
I was just working on the VAX LISP hashing functions when I noticed that
the description of :REHASH-THRESHOLD has deteriorated a bit since the
Colander edition. The silver book says that it can be an integer greater
than zero and less than the :REHASH-SIZE. This makes no sense when you
read the description of :REHASH-SIZE. It also says it can be a float
between zero and one. Is this a percentage of the size or the rehash size?
- Paul
∂20-Dec-84 1439 RPG Common Lisp Specification
∂19-Dec-84 0935 OHLANDER@USC-ISI.ARPA Common Lisp Specification
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 09:35:30 PST
Date: 19 Dec 1984 12:35-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Common Lisp Specification
From: OHLANDER@USC-ISI.ARPA
To: Squires@USC-ISI.ARPA, Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA, Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]19-Dec-84 12:35:19.OHLANDER>
Gentlemen,
I have just talked with John Osbourne at Digital Press and we
appear to have mutual agreement on rights to the Common Lisp spec.
The Common Lisp User's Group will have rights to the specification.
In turn, the group will give Digital Press commercial printing rights
when published documents are needed. Digital Press will publish
appropriate changes and will also furnish packages to other vendors for
a reasonable licensing fee. John Osbourne has also said that they
may be able to feed some portion of profits back to the User's Group
which would help meet expenses.
Sam Fuller of DEC has suggested that we try to get the User's Group
chartered under the AAAI. I think the idea has merit. What do
you all think?
Ron
P. S. Dick, will you make sure that the other members of the
original five get a copy of this message?
∂20-Dec-84 1439 RPG Re: Common Lisp Specification
∂19-Dec-84 1024 STEELE@TL-20A.ARPA Re: Common Lisp Specification
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 10:24:01 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Wed 19 Dec 84 13:23:16-EST
Date: Wed 19 Dec 84 13:22:55-EST
From: STEELE@TL-20A.ARPA
Subject: Re: Common Lisp Specification
To: OHLANDER@USC-ISI.ARPA
cc: Squires@USC-ISI.ARPA, Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA,
STEELE@TL-20A.ARPA
In-Reply-To: Message from "OHLANDER@USC-ISI.ARPA" of Wed 19 Dec 84 12:35:00-EST
Being chartered under AAAI sounds reasonable to me. I myself
don't know a great deal about AAAI's organizational structure,
but they would be a relatively neutral, existing bureaucracy
(in all the good senses of the wored), disinterested but not
uninterested. That sounds much more appealing than trying to
charter a stand-alone group.
--Guy
-------
∂21-Dec-84 0619 NET-ORIGIN@MIT-MC Does anyone understand :REHASH-THRESHOLD?
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 21 Dec 84 06:19:27 PST
Received: by mit-eddie.Mit-chaos.Arpa id AA02521; Fri, 21 Dec 84 09:08:47 est
Received: by godot with CHAOS id AA24059; Fri, 21 Dec 84 08:54:43 est
Date: Friday, 21 December 1984, 08:54-EST
From: Dan Aronson <godot!Dan@AQUINAS>
Reply-To: mit-eddie!Dan%godot%mit-mc at AQUINAS
Subject: Does anyone understand :REHASH-THRESHOLD?
To: mit-eddie!common-lisp%su-ai.arpa@GODOT
In-Reply-To: <8412201513.AA21378@mit-eddie.Mit-chaos.Arpa>
I've just reread the definitions of :REHASH-SIZE and :REHASH-THRESHOLD in
the silver book and they both seem perfectly clear. If :REHASH-THRESHOLD is
an integer less than :REHASH-SIZE (where :REHASH-SIZE must be an integer)
then when the table grows greater then threshold/size percent it is grown.
However, if :REHASH-THRESHOLD is a fraction, then that is the percentage
that is used. I think that common sense has to be assumed when reading some
of this stuff.
--Dan Aronson
∂21-Dec-84 2235 BSG@SCRC-QUABBIN.ARPA No, I'm not joking
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 21 Dec 84 22:35:23 PST
Received: from SCRC-CONCORD by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 115481; Thu 20-Dec-84 14:57:18-EST
Date: Thu, 20 Dec 84 14:53 EST
From: "Bernard S. Greenberg" <BSG@SCRC-QUABBIN.ARPA>
Subject: No, I'm not joking
To: lisp-designers@SCRC-QUABBIN.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <841220145308.8.BSG@CONCORD.SCRC.Symbolics.COM>
FLET* wants very badly to be.
∂22-Dec-84 1137 @MIT-MC:BSG%SCRC-TENEX%MIT-MC@STANFORD Re: No, I'm not joking
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 11:37:00 PST
Date: 22 Dec 1984 1130-EST
From: Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC@STANFORD>
Subject: Re: No, I'm not joking
To: RAM%CMU-CS-C@STANFORD
cc: common-lisp@SAIL, lisp-designers%SCRC-QUABBIN%MIT-MC@STANFORD
In-Reply-To: <RAM.12073474734.BABYL@CMU-CS-C.ARPA>
DATE: Sat, 22 Dec 1984 10:37 EST
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA> ;
WHAT do you want to use FLET* for that LABELS won't do? There
obviously is a difference, but I can't think of a place where the
difference is useful.
We've had some internal discussion on this, here. Inconclusive, but
I feel less strongly, as a result. Let me try to summarize some of the
discussion, and some of my feelings.
LABELS implies full recursivity and mutual recursivity. This may
be harder than simply-nested single FLET's for some implementations,
vis-a-vis allocation of closures, sharing of stack frames, etc.
Some implementations might say, for LABELS, "Oh this the hard case",
and do something less efficient than either full analysis or
nested FLET's would allows.
There is also a conceptual issue, that when I see LABELS, *I* say
"Ohh, something trickily recursive or mutually-recursive is
going to happen here!" This may be sheer prejudice, and completely
unreasonable. This may be the heart of the issue.
Then there is the parallel to LET "issue", which is admittedly
not an issue, because there is no effect of "executing" the
function definition.
"So you can always use nested FLET's, if you think that's
clearer." But that plays havoc with the indentation
(that *IS* an issue). Then there was this comic dialogue
between Moon and myself, "Oh, so who needs LET*, you can
use nested LET's". "But you can't, because LET* allows
declarations". So same for FLET*, except there's nothing
you could possibly want to declare, out of the current
set of CL declarations. But FLET doesn't allow body
declarations, anyway! Well, on one page the CLM says
it does, and on another it doesn't, (we implement
"no, it doesn't")....
-------
∂22-Dec-84 1152 RAM@CMU-CS-C.ARPA No, I'm not joking
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 11:52:03 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 22 Dec 84 14:22:50-EST
Date: Sat, 22 Dec 1984 10:37 EST
Message-ID: <RAM.12073474734.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG@SCRC-QUABBIN.ARPA>
Cc: common-lisp@SU-AI.ARPA, lisp-designers@SCRC-QUABBIN.ARPA
Subject: No, I'm not joking
In-reply-to: Msg of 20 Dec 1984 14:53-EST from Bernard S. Greenberg <BSG at SCRC-QUABBIN.ARPA>
What do you want to use FLET* for that LABELS won't do? There
obviously is a difference, but I can't think of a place where the
difference is useful.
Rob
∂22-Dec-84 1214 RAM@CMU-CS-C.ARPA No, I'm not joking
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Dec 84 12:14:37 PST
Received: ID <RAM@CMU-CS-C.ARPA>; Sat 22 Dec 84 15:15:19-EST
Date: Sat, 22 Dec 1984 15:15 EST
Message-ID: <RAM.12073525294.BABYL@CMU-CS-C.ARPA>
From: Rob MacLachlan <RAM@CMU-CS-C.ARPA>
To: "Bernard S. Greenberg" <BSG%SCRC-TENEX@MIT-MC.ARPA>
Cc: common-lisp@SU-AI.ARPA, lisp-designers%SCRC-QUABBIN@MIT-MC.ARPA
Subject: No, I'm not joking
In-reply-to: Msg of 22 Dec 1984 11:30-EST from Bernard S. Greenberg <BSG%SCRC-TENEX%MIT-MC at STANFORD>
The syntax given for FLET definitely disallows any body
declarations. The manual may be consistent in forbidding declarations
in FLET, depending on how the definition of DECLARE (153-154) is
interpreted. All that is precisely stated is that FLET, LABELS and
MACROLET do allow declarations, which is indeed true, since they
allow declarations within the definitions of the local functions or
macros. If this is the case, then the description of where
declarations appear should probably be made more specific or less
specific so that it doesn't appear to be saying something which is
untrue.
Although declarations may not be allowed in FLET, it is untrue
that to allow them would be useless. The INLINE declaration could be
quite meaningfully applied.
Rob
∂26-Dec-84 1201 RPG Common Lisp Specification
∂19-Dec-84 0935 OHLANDER@USC-ISI.ARPA Common Lisp Specification
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 09:35:30 PST
Date: 19 Dec 1984 12:35-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Common Lisp Specification
From: OHLANDER@USC-ISI.ARPA
To: Squires@USC-ISI.ARPA, Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA, Steele@TL-20B.ARPA
Message-ID: <[USC-ISI.ARPA]19-Dec-84 12:35:19.OHLANDER>
Gentlemen,
I have just talked with John Osbourne at Digital Press and we
appear to have mutual agreement on rights to the Common Lisp spec.
The Common Lisp User's Group will have rights to the specification.
In turn, the group will give Digital Press commercial printing rights
when published documents are needed. Digital Press will publish
appropriate changes and will also furnish packages to other vendors for
a reasonable licensing fee. John Osbourne has also said that they
may be able to feed some portion of profits back to the User's Group
which would help meet expenses.
Sam Fuller of DEC has suggested that we try to get the User's Group
chartered under the AAAI. I think the idea has merit. What do
you all think?
Ron
P. S. Dick, will you make sure that the other members of the
original five get a copy of this message?
∂26-Dec-84 1201 RPG Re: Common Lisp Specification
∂19-Dec-84 1024 STEELE@TL-20A.ARPA Re: Common Lisp Specification
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 19 Dec 84 10:24:01 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Wed 19 Dec 84 13:23:16-EST
Date: Wed 19 Dec 84 13:22:55-EST
From: STEELE@TL-20A.ARPA
Subject: Re: Common Lisp Specification
To: OHLANDER@USC-ISI.ARPA
cc: Squires@USC-ISI.ARPA, Fahlman@CMU-CS-C.ARPA, RPG@SU-AI.ARPA,
STEELE@TL-20A.ARPA
In-Reply-To: Message from "OHLANDER@USC-ISI.ARPA" of Wed 19 Dec 84 12:35:00-EST
Being chartered under AAAI sounds reasonable to me. I myself
don't know a great deal about AAAI's organizational structure,
but they would be a relatively neutral, existing bureaucracy
(in all the good senses of the wored), disinterested but not
uninterested. That sounds much more appealing than trying to
charter a stand-alone group.
--Guy
-------
∂26-Dec-84 1209 RPG AAAI
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA
I've mentioned it before, but I'd like to re-make the point that I
would strongly resist becoming chartered under AAAI. There are two
reasons. First, if we are under AAAI, then we are stating that Lisp is
a sub-discipline or a subpart of AI. I personally do not want to
make that statement.
Second, the Lisp conference has always scheduled itself the same week
and at the same place as AAAI. The last two times, AAAI has reneged on
promises to not schedule on top of the Lisp conference, even though
the Lisp conference has tried to cut back its schedule to accomodate
AAAI. The Lisp conference (and SIGPLAN) has decided to no longer
be affiliated with AAAI.
I think that Common Lisp deserves first class treatment, not second class.
On Digital Press. I feel a little uneasy about Digital Press being
the ones to always be responsible for publishing Common Lisp stuff,
especially given that they've dragged their feet with Data General.
If we give them this plum, then I think we ought to exact a contractul
obligation for haste and diligence on matters like these.
-rpg-
∂26-Dec-84 1332 FAHLMAN@CMU-CS-C.ARPA AAAI
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 26 Dec 84 13:32:41 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 26 Dec 84 16:33:24-EST
Date: Wed, 26 Dec 1984 16:33 EST
Message-ID: <FAHLMAN.12074588088.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: Dick Gabriel <RPG@SU-AI.ARPA>
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA
Subject: AAAI
In-reply-to: Msg of 26 Dec 1984 15:09-EST from Dick Gabriel <RPG at SU-AI.ARPA>
I agree with Dick Gabriel that the organizing body for Common Lisp ought
to be independent of AAAI if we can manage this, because the interests
of the two organizations do not totally overlap. At any given time, the
rotating leadership of AAAI may be in the hands of an anti-Lisp faction,
or at least a group that feels that making Lisp a better language for
system programming is not an interesting task for AAAI. I haven't been
involved in the Lisp Conference business, so I can't say whether the
problems between that conference and AAAI were the result of malice,
indifference, or just bad planning and communication, but it's a bad
sign in any case.
Since there has been so little feedback from the charter group, I'm
going to take the drastic step of proposing what I think would be a good
organization all by myself, and then telling people that silence will be
taken as agreement. I'm working on that proposal now. If you like, I
can be sure that all of you see it before I send it out to the others.
It proposes an independent organization (tentaively named the "Common
Lisp Association" -- I think that "Users' Group" is too restricitve)
with individual and corporate members. The latter will pay for it all
with dues of $20K/year or so. For that, they get assorted services such
as validation of their systems at cost and the right to use the
"Validated Common Lisp" trademark in their advertising for validated
products.
As for Digital Press, I agree that the most critical issue is who gets
to negotiate the contracts for the use of the manual in other forms:
online use, limited printings by other manufacturers, etc. Digital
Press, by their delaying tactics, have demonstrated that we can't
leave control of this matter entirely in their hands. If they had been
reasonable in handling requests from Data General and otehrs, this whole
issue would not have arisen.
-- Scott
∂26-Dec-84 1456 RPG Independence
To: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA
Gentlemen,
John McCarthy sent this to me today after I showed him the recent
mail amongst us:
∂26-Dec-84 1308 JMC Common Lisp sponsored by another organization
My opinion is that Common Lisp should not be sponsored by any other
organization as long as the five are willing to keep it alive and
unless there arises a political difficulty making it desirable to
find a neutral sponsor, e.g. if the five are considered unneutral
by some force that it is important to mollify. It will actually
be less trouble for you than explaining things to the sponsoring
organization. If you need another individual to lend weight, I'm
available provided it isn't too much work.
If you want to circulate this, go ahead.
∂28-Dec-84 1112 STEELE@TL-20A.ARPA Re: Independence
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 28 Dec 84 11:11:49 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Fri 28 Dec 84 14:13:20-EST
Date: Fri 28 Dec 84 14:13:15-EST
From: STEELE@TL-20A.ARPA
Subject: Re: Independence
To: RPG@SU-AI.ARPA
cc: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA, STEELE@TL-20A.ARPA
In-Reply-To: Message from "Dick Gabriel <RPG@SU-AI.ARPA>" of Wed 26 Dec 84 14:56:00-EST
As it happens, I have just finished speaking with Sam Fuller of DEC,
and shortly afterwards saw RPG's forwarding of JMC's note. I have
also received today a letter dated December 17 from John Osborn
in which Osborn states that he expects the DG contract to be polished
up and a copy sent to me "next week" (i.e., by today, December 28).
Sam indicated his continued support of Common Lisp and a desire to minimize
red tape. He brought up again to me the idea of channeling some money
from the book into a Common Lisp organization to support work on
future language revisions. I expressed Scott's concern that while that
is all very well, it should not be allowed to delay pending negotiations,
and Sam agreed with that.
I have received today a copy of a letter from Franz, Inc., to Digital
Press (which Franz, Inc. cc'd to me) inquiring about what arrangements
are possible for using the Common Lisp manual text in other documentation.
I mentioned this fact to Sam, and he repeated back to me the understanding
that the manual must be reprinted whole, possibly with additions. H
volunteered a remark that there will be great pressure to relax this
arrangement to permit arbitrary borrowing and rewriting of text, and that
this pressure must be resisted, even if it comes from DEC itself.
(He said that!)
Sam would like to see some action fairly soon to set up an identifiable
entity that is responsible for Common Lisp. I agreed to discuss the issues
further with you all, and investigate fairly promptly whether AAAI is
an appropriate organization to work with on this. Maybe working with them
would be hard, but then setting up and maintaining an independent
bureaucracy is also hard: if money is involved, it means a fair amount
of legal structure and paperwork, as well as accounting functions.
--Guy
-------
∂29-Dec-84 0559 NET-ORIGIN@MIT-MC Irrational GCD
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 29 Dec 84 05:59:45 PST
Received: from SPA-LOS-TRANCOS by SPA-RUSSIAN via CHAOS with CHAOS-MAIL id 73170; Fri 28-Dec-84 23:38:17-PST
Date: Fri, 28 Dec 84 23:38 PST
From: Bill Gosper <rwg@NIMBUS.SPA.Symbolics>
Subject: Irrational GCD
To: common-lisp at SU-AI@MIT-MC.ARPA
In-Reply-To: (failed mail)<841219234502.1.NFEP@NEPONSET.SCRC.Symbolics.COM>
Message-ID: <841228233821.5.RWG@LOS-TRANCOS.SPA.Symbolics>
Date: Wednesday, 19 December 1984, 23:45-EST
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN>
[(GCD 1\4 1\3) errs.]
. . .
BTW, the correct answer is 1\12.
Not as far as ZL is concerned. Nor CL for that matter.
Ouch! They must have been jet-lagged at those CL meetings. As
Schroeppel pointed out several millenia back,
(GCD A\B C\D) = (GCD A C)/(LCM B D),
assuming args are in lowest terms. MACSYMA has long known this.
But the absoLULU is further down page 202 of the CL book:
"Mathematically, (lcm) should return infinity." This is so wildly
absurd that I can't even guess the fallacy that led to it. It should
simply be 1.
∂01-Jan-85 1916 FAHLMAN@CMU-CS-C.ARPA Yellow pages
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 1 Jan 85 19:15:52 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Tue 1 Jan 85 22:16:47-EST
Date: Tue, 1 Jan 1985 22:16 EST
Message-ID: <FAHLMAN.12076223454.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Yellow pages
On several occasions I have started to collect all of the random code
files lying around here into an online libarary that, if it grows and
prospers, would eventually become the Yellow pages (or one version of
the yellow pages, anyway). Then I get to thinking about what sort of
boilerplate to include in these files, and I end up putting the whole
thing off until I have time to think about this. Well, here we go
again, and this time I'll ask for advice:
What information do we want to include with each program? My initial
list is as follows:
A copyright notice or statement that the code is in the public domain.
Author's name.
Current maintainer, with mail and net address.
Description of the program (optional if there is a document).
Notes on any non-portable aspects of the code.
Known bugs and ideas for future extension.
Log of significant changes from one release to another.
Random comments.
Anything else? Should this be in the same file as the code (in a big
initial comment), or a separate-but-related file? Should we try to come
up with some syntax for making the fields easily identifiable by
machine, or is human-readability sufficient?
Probably we'll have two library directories, one for truly portable
stuff and another, much larger, for Perq-specific code (which still
might be of considerable use to people writing similar programs).
-- Scott
∂01-Jan-85 2003 fateman%ucbdali@Berkeley Re: Yellow pages
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 1 Jan 85 20:03:16 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.40)
id AA28566; Tue, 1 Jan 85 19:56:21 pst
Received: by ucbdali.ARPA (4.24/4.40)
id AA24419; Tue, 1 Jan 85 20:03:13 pst
Date: Tue, 1 Jan 85 20:03:13 pst
From: fateman%ucbdali@Berkeley (Richard Fateman)
Message-Id: <8501020403.AA24419@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, common-lisp@SU-AI.ARPA
Subject: Re: Yellow pages
I think the best legal notice would include the copyright by the author
or owner, followed by a permission to reproduce, redistribute, revise,
etc. The fewer conditions the better. One kind of condition that
some people have a lot of trouble with is one that requires that
all revisions are public domain... it could mean that if that code
is merged with other (proprietary) code, it all becomes public domain.
E.g. how would Lucid feel about using a yellow-pages editor if it meant
their compiler became public...
Where is the lawyer on this project, anyway?
∂02-Jan-85 0618 OHLANDER@USC-ISI.ARPA Re: AAAI
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 2 Jan 85 06:18:09 PST
Date: 2 Jan 1985 09:18-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: AAAI
From: OHLANDER@USC-ISI.ARPA
To: RPG@SU-AI.ARPA
Cc: quinquevirate@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 2-Jan-85 09:18:25.OHLANDER>
In-Reply-To: The message of 26 Dec 84 1209 PST from Dick Gabriel <RPG@SU-AI.ARPA>
Dick,
Given your opposition to becoming affiliated with AAAI, is their
any other organization you would choose as a sponsor?
Ron
∂02-Jan-85 0631 OHLANDER@USC-ISI.ARPA Re: Independence
Received: from USC-ISI.ARPA by SU-AI.ARPA with TCP; 2 Jan 85 06:31:39 PST
Date: 2 Jan 1985 09:31-EST
Sender: OHLANDER@USC-ISI.ARPA
Subject: Re: Independence
From: OHLANDER@USC-ISI.ARPA
To: RPG@SU-AI.ARPA
Cc: quinquevirate@SU-AI.ARPA
Message-ID: <[USC-ISI.ARPA] 2-Jan-85 09:31:54.OHLANDER>
In-Reply-To: The message of 26 Dec 84 1456 PST from Dick Gabriel <RPG@SU-AI.ARPA>
Dick,
I can see that there is a fairly strong feeling against affiliating
with anyone at this point in regards to Common Lisp. If that is the wish
of the majority, I certainly will not press the issue.
In regards to Digital Press, I don't think we have too much choice concerning
cooperation with them unless we wan't to stir up legal controversy. I had
a talk with Osbourne and he explained that initial difficulties arose
because the lawyers did not understand the role of Common Lisp in regards
to the world of computers. They were treating the manual as just another
book. Sam Fuller took some trouble to explain the issues and
they appear to have become very cooperative. I suggest that we proceed
to keep dealing with them, letting them understand the need to be
cooperative and responsive. If things then deteriorate we can
take some additional action. We may want to get some agreement from them
in writing.
Ron
∂02-Jan-85 0738 FAHLMAN@CMU-CS-C.ARPA Yellow pages
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 2 Jan 85 07:38:00 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Wed 2 Jan 85 10:36:10-EST
Date: Wed, 2 Jan 1985 10:36 EST
Message-ID: <FAHLMAN.12076358057.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: fateman%ucbdali@λBerkeley (Richard Fateman)λ
Cc: common-lisp@SU-AI.ARPA
Subject: Yellow pages
In-reply-to: Msg of 1 Jan 1985 23:03-EST from fateman%ucbdali at Berkeley (Richard Fateman)
Good point. Public domain seems to work just fine, but a copyright by
the author with all of the permissions you list would have much the same
effect.
Yes, we really do have to get us a lawyer; not having one to consult at
CMU has already led to some mistakes on this stuff, I think. I guess
some of the DARPA "seed money" for setting up this organization is going
to have to flow in that direction, unless some company out there can
loan us a lawyer on occasion -- doubtful, since this could lead to
conflict of interest.
-- Scott
∂02-Jan-85 1332 kessler%utah-orion@utah-cs re: Yellow pages
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 2 Jan 85 13:32:04 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1)
id AA29346; Wed, 2 Jan 85 14:30:55 MST
Received: by utah-orion.ARPA (4.42/4.40.1)
id AA09300; Wed, 2 Jan 85 14:28:12 MST
Message-Id: <8501022128.AA09300@utah-orion.ARPA>
Date: 2 Jan 85 14:15 MST
From: Robert Kessler <kessler%utah-orion@utah-cs>
To: fahlman@cmu-cs-c
Cc: common-lisp@su-ai
Subject: re: Yellow pages
> What information do we want to include with each program? My initial
> list is as follows:
>
> A copyright notice or statement that the code is in the public domain.
I agree that a copyright notice along with the appropriate release.
> Author's name.
And address.
> Current maintainer, with mail and net address.
> Description of the program (optional if there is a document).
I would still require a brief description.
> Notes on any non-portable aspects of the code.
> Known bugs and ideas for future extension.
> Log of significant changes from one release to another.
> Random comments.
>
> Anything else? Should this be in the same file as the code (in a big
> initial comment), or a separate-but-related file? Should we try to come
It should be in the same file. Its hard enough tracking down code
across multiple files, without the necessity of looking for the
documentation in some other place.
> up with some syntax for making the fields easily identifiable by
> machine, or is human-readability sufficient?
I would make a standard form of comments where there is a keyword before
each piece of information. Then a fairly simple program can have
access. We use a scheme devised at HP which creates a header like the
following, along with a revision list:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% File: MINI-SUPPORT.SL
% Description: A Small Meta System (Support routines for mini.min/mini.sl)
% Author: Robert Kessler, Utah PASS Project
% Created: 01-Jan-79
% Modified: 9-Mar-84 15:05:06 (Robert Kessler)
% Mode: Lisp
% Status: Experimental (Do Not Distribute)
%
% (c) Copyright 1979, University of Utah, all rights reserved.
>>>> Put in some kind of release statement
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Revisions:
%
% 9-Mar-84 15:03:40 (Robert Kessler)
% Added fluid definition of !*writingfaslfile, and modified
% rule-define, so it does a boundp check before accessing the value of
% the variable. For strange reasons, this a call to an undefined
% function if the compiler wasn't loaded.
% 27-Feb-84 11:58:47 (Robert Kessler)
% Added Legal-single-char to check to see if a keyword is an
% alphanumeric character. We do not want to make an alphanumeric
% character a keyword. This would make words with that letter in it
% invalid. Therefore, if the grammar definer makes something a
% keyword (like 't), it must be separated by other delimiters.
% ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The NMODE text editor automatically updates the last modified line any
time you write the file out.
Bob.
∂02-Jan-85 1357 kessler%utah-orion@utah-cs re: Yellow pages
Received: from UTAH-CS.ARPA by SU-AI.ARPA with TCP; 2 Jan 85 13:56:53 PST
Received: from utah-orion.ARPA by utah-cs.ARPA (4.42/4.40.1)
id AA29829; Wed, 2 Jan 85 14:56:01 MST
Received: by utah-orion.ARPA (4.42/4.40.1)
id AA09462; Wed, 2 Jan 85 14:51:18 MST
Date: Wed, 2 Jan 85 14:51:18 MST
From: kessler%utah-orion@utah-cs (Robert Kessler)
Message-Id: <8501022151.AA09462@utah-orion.ARPA>
Cc: common-lisp@su-ai.arpa
Subject: re: Yellow pages
--------
> What information do we want to include with each program? My initial
> list is as follows:
>
> A copyright notice or statement that the code is in the public domain.
I agree that a copyright notice along with the appropriate release.
> Author's name.
And address.
> Current maintainer, with mail and net address.
> Description of the program (optional if there is a document).
I would still require a brief description.
> Notes on any non-portable aspects of the code.
> Known bugs and ideas for future extension.
> Log of significant changes from one release to another.
> Random comments.
>
> Anything else? Should this be in the same file as the code (in a big
> initial comment), or a separate-but-related file? Should we try to come
It should be in the same file. Its hard enough tracking down code
across multiple files, without the necessity of looking for the
documentation in some other place.
> up with some syntax for making the fields easily identifiable by
> machine, or is human-readability sufficient?
I would make a standard form of comments where there is a keyword before
each piece of information. Then a fairly simple program can have
access. We use a scheme devised at HP which creates a header like the
following, along with a revision list:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% File: MINI-SUPPORT.SL
% Description: A Small Meta System (Support routines for mini.min/mini.sl)
% Author: Robert Kessler, Utah PASS Project
% Created: 01-Jan-79
% Modified: 9-Mar-84 15:05:06 (Robert Kessler)
% Mode: Lisp
% Status: Experimental (Do Not Distribute)
%
% (c) Copyright 1979, University of Utah, all rights reserved.
>>>> Put in some kind of release statement
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% Revisions:
%
% 9-Mar-84 15:03:40 (Robert Kessler)
% Added fluid definition of !*writingfaslfile, and modified
% rule-define, so it does a boundp check before accessing the value of
% the variable. For strange reasons, this a call to an undefined
% function if the compiler wasn't loaded.
% 27-Feb-84 11:58:47 (Robert Kessler)
% Added Legal-single-char to check to see if a keyword is an
% alphanumeric character. We do not want to make an alphanumeric
% character a keyword. This would make words with that letter in it
% invalid. Therefore, if the grammar definer makes something a
% keyword (like 't), it must be separated by other delimiters.
% ...
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The NMODE text editor automatically updates the last modified line any
time you write the file out.
Bob.
------- End of Forwarded Message
∂05-Jan-85 1007 @MIT-MC:ALAN@SCRC-TENEX Irrational GCD
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 5 Jan 85 10:07:06 PST
Date: Saturday, 5 January 1985 04:19-EST
From: Alan Bawden <ALAN at SCRC-TENEX>
To: Bill Gosper <rwg at SPA-NIMBUS>
Cc: BUG-LISPM at SWW-WHITE, common-lisp at SU-AI, DCP at SCRC-QUABBIN,
numerics at SPA-NIMBUS
Subject: Irrational GCD
Date: Friday, 28 December 1984, 01:28-PST
From: Bill Gosper <rwg at SPA-NIMBUS>
Date: Wednesday, 19 December 1984, 23:45-EST
From: David C. Plummer in disguise <DCP at SCRC-QUABBIN>
[(GCD 1\4 1\3) errs.]
. . .
BTW, the correct answer is 1\12.
Not as far as ZL is concerned. Nor CL for that matter.
Ouch! They must have been jet-lagged at those CL meetings. As
Schroeppel pointed out several millenia back,
(GCD A\B C\D) = (GCD A C)/(LCM B D),
assuming args are in lowest terms. MACSYMA has long known this.
You know Gosper, I had always assumed that people who proposed to extend
GCD to the rationals were just confused about just what GCD really was, so
I was quite surprised to hear that this was an idea endorsed by Schroeppel.
So I thought about it for a while...
In what sense must the GCD of 1/3 and 1/4 be 1/12? Suppose I pick some
subring of Q that contains both 1/3 and 1/4 and I look at the ideal
generated by 1/3 and 1/4. Certainly that ideal is the same as the ideal
generated by 1/12, and in general the formula you give above will always
yeild such a generator, but there are many other elements in the ring that
generate that ideal. In fact, since 1/12 is a unit in any subring of Q,
that ideal must be generated by 1, so why not say GCD(1/3,1/4)=1? What is
the additional constraint you impose that requires 1/12?
Well, suppose that instead of thinking about GCD as defined in terms of
generators of ideals in subrings of Q, we think about GCD as defined in
terms of generators of Z-modules contained in Q. In that case, the formula
above gives the unique (modulo sign) generator of the module generated by
the arguments to GCD. But that seems somewhat arbitrary; suppose I was
working with some ring other than Z, call it A, and I wanted to play with
A-modules contained in Q? No problem! Although the formula can't always
give you a unique generator, it will give you -one- of the generators,
which is certainly the best you can ask for.
Summary: I'm convinced. This really is the right way to extend GCD to the
rational numbers if you are going to do it at all. (Since my suggestions
that GCD, NUMERATOR and DENOMINATOR be extended in the -only- possible way to
the complex integers were ignored, I have little hope that Common Lisp will
adopt the idea, however.)
But the absoLULU is further down page 202 of the CL book:
"Mathematically, (lcm) should return infinity." This is so wildly
absurd that I can't even guess the fallacy that led to it. It should
simply be 1.
It is clearly a result of taking the identity
(LCM ...) = (/ (ABS (* ...)) (GCD ...))
too seriously.
∂07-Jan-85 0807 DLW@SCRC-STONY-BROOK.ARPA Independence
Received: from SCRC-STONY-BROOK.ARPA by SU-AI.ARPA with TCP; 7 Jan 85 08:06:56 PST
Received: from SCRC-CHICOPEE by SCRC-STONY-BROOK via CHAOS with CHAOS-MAIL id 152936; Fri 4-Jan-85 13:57:07-EST
Date: Fri, 4 Jan 85 13:56 EST
From: Daniel L. Weinreb <DLW@SCRC-STONY-BROOK.ARPA>
Subject: Independence
To: RPG@SU-AI.ARPA, quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA
In-Reply-To: The message of 26 Dec 84 17:56-EST from Dick Gabriel <RPG@SU-AI.ARPA>
Message-ID: <850104135634.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
I don't have anything to add, but I wanted to let you know I'm still
here, and I agree that we should avoid being sponsored by AAAI, for
the reasons that have been mentioned.
∂14-Jan-85 1523 RPG on the cl graphics list?
∂14-Jan-85 1144 wahrman@WHITE.SWW.Symbolics.COM on the cl graphics list?
Received: from SCRC-QUABBIN.ARPA by SU-AI.ARPA with TCP; 14 Jan 85 11:43:15 PST
Received: from SWW-WHITE by SCRC-QUABBIN via CHAOS with CHAOS-MAIL id 121832; Mon 14-Jan-85 14:23:27-EST
Received: from SWW-BROWN by SWW-WHITE via CHAOS with CHAOS-MAIL id 78813; Mon 14-Jan-85 11:22:45-PST
Date: Mon, 14 Jan 85 11:24 PST
From: Michael Wahrman <wahrman%SWW-WHITE@SCRC-QUABBIN.ARPA>
Subject: on the cl graphics list?
To: rpg@SU-AI.ARPA
Cc: wahrman@WHITE
Hello there,
I'd like to be on the common lisp graphics discussion. I'm a computer
graphics special effects designer.
Thanks.
Michael Wahrman
Wahrman%white@scrc-riverside
or mlw@rand-unix (which gets forwarded)
Done.
∂16-Jan-85 0423 JonL.pa@Xerox.ARPA Silicon Valley Syndrome
Received: from XEROX.ARPA by SU-AI.ARPA with TCP; 16 Jan 85 04:23:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 JAN 85 04:24:30 PST
Date: 16 Jan 85 04:23 PST
From: JonL.pa@XEROX.ARPA
Subject: Silicon Valley Syndrome
To: Common-Lisp@SU-AI.ARPA
cc: JonL.pa@XEROX.ARPA
Today I am returning to the Common Lisp world by joining Lucid, Inc., a
new start-up company founded by Dick Gabriel. Lucid will be developing
Common Lisp systems for a variety of different hardwares, as well as
doing other related software R&D.
I've enjoyed the past 2 1/2 years working on Interlisp-D at Xerox, and
am looking forward to the many opportunities in this growing new
company. I invite you all to contact me, after today, at
Jon L White
Lucid, Inc.
1090 East Meadow Circle
Palo Alto CA 94303
415-424-8855
For a period of time, my ArpaNet mail addresses will be
JONL@MC
JLW@SU-AI
-- JonL --
∂18-Jan-85 1453 HANDERSON@CMU-CS-C.ARPA Filtering calls
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 18 Jan 85 14:53:43 PST
Received: ID <HANDERSON@CMU-CS-C.ARPA>; Fri 18 Jan 85 17:54:58-EST
Date: Fri, 18 Jan 1985 17:54 EST
Message-ID: <HANDERSON.12080632243.BABYL@CMU-CS-C.ARPA>
From: Steven <Handerson@CMU-CS-C.ARPA>
To: common-lisp@SU-AI.ARPA
Subject: Filtering calls
The current language definition seems to have a small problem.
I'll follow through a hack example - anyone with any imagination should see the
problem (whether my example means anything is a separate issue).
Let's assume that you have to write (VAR X) instead of X to reference a given
variable (and, for convenience, that everything works like SETF). The global
macro for VAR does the normal variable thing.
DEFMETHOD could then *filter* through the calls to VAR for those of instance
variables, replacing them with calls to a macro IV, and leaving the rest for
the global macro. How can we set up such a filter? We can't just deal with
the global definition, because someone might want to filter the remaining VARs
in some code wrapped around ours. Macrolet would cause the remaining VARs to
be examined again and again... I think we need some way to deal with expansion
functions explicitly, but I'm not sure.
-- Steve
∂21-Jan-85 2002 FAHLMAN@CMU-CS-C.ARPA A proposal
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 21 Jan 85 20:02:39 PST
Received: ID <FAHLMAN@CMU-CS-C.ARPA>; Mon 21 Jan 85 22:52:33-EST
Date: Mon, 21 Jan 1985 22:52 EST
Message-ID: <FAHLMAN.12081472823.BABYL@CMU-CS-C.ARPA>
Sender: FAHLMAN@CMU-CS-C.ARPA
From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
To: cl-charter@SU-AI.ARPA
Cc: quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA, squires@USC-ISI.ARPA
Subject: A proposal
OK, we've got to get this charter business settled. The status quo is
untenable in the long run. I guess we need a specific proposal to focus
our discussions. There seem to be three possible models:
1. A separate organization for Common Lisp.
2. Setting up a subcommittee of AAAI or some other existing organization
to handle Common Lisp activities.
3. Trying to get by without any formal organization. Guy would put
whatever he wants into future editions of the book, DARPA would
specify whatever they want as a standard (with a validation suite
owned by them), CMU and others might produce some public domain code
if they feel like it, manufacturers do whatever they want to and call
it Common Lisp if they feel like it, and the rest of us kibitz and
try to offer good but informal advice to all of the above.
I think that most of us prefer plan 1, a separate organization, if such
an organization can be set up in some way that makes it viable.
Therefore, I propose to explore in this document what such an
organization might look like. If we can't find a satisfactory solution
of this form, then it is time to look at the other options.
I share the concern expressed by Dick Gabriel (and by James Madison and
Alexander Hamilton) that raw democracy is not the best way to decide
complex technical issues. The traditional fix is to set up a
representative system in which the decisions are made by a small group
of people who are elected by, and derive their legitimacy from, the
community as a whole. We also need some constitutional checks and
balances to prevent any sudden and disruptive lurches in the design.
All of us have our own axes to grind, but I think that most of us feel
that overall stability of the language is of over-riding importance.
The following proposal is just a sketch. Random comments and queries
are in square brackets. Obviously it will take a certain amount of
work, by someone with experience in such organizational matters, to turn
this outline into a proper set of bylaws. Since there is significant
money involved, as well as a number of liability and antitrust issues,
we're going to need good legal advice on this BEFORE we start signing up
members. That's one place where the DARPA seed money comes in, I hope.
Let me know what you think about this. I'm not particularly attached to
any of the details of this plan. Alternative plans are welcome. Keep
in mind that we've got to do SOMETHING about an organization, so vague
objections that are not accompanied by reasonable counter-proposals
won't be taken very seriously.
-- Scott
---------------------------------------------------------------------------
1. OVERVIEW
The proposal is to create a non-profit corporation to be called the
"Common Lisp Association". The purpose of this organization is to
promote the standardization and orderly evolution of the Common Lisp
language and to support efforts to enhance the usefulness of all Common
Lisp implementations.
This organization will have both individual and corporate members. The
dues from the corporate members will be its principal source of income.
2. FUNCTIONS OF THE ASSOCIATION
2.1 To maintain and distribute the official language definition and a
matching validation suite. This involves a certain amount of
decision-making to resolve ambiguities in the manual, consider proposed
changes and extensions and perhaps adopt them, and to create related
standards in areas outside the language proper. All decisions must be
carefully recorded and communicated to all interested parties.
2.2 To serve as the legal entity that acts on behalf of the Common Lisp
community. In this capacity, the organization would be the holder of
any trademarks or copyrights that are under control of "the Common Lisp
community" and not of any single company or group. In particular, the
organization will obtain a trademark for "Validated Common Lisp", and
will control its use.
2.3 To perform official validation of Common Lisp implementations. Only
those implementations that have passed an official validation test at
some level will be authorized to use the "Validated Common Lisp"
trademark. From time to time, new validation suites will be produced,
and anyone using the trademark will be required to include an
appropriate explanation, such as "Complies fully with the 1986 Common
Lisp Standard, minus complex numbers".
2.4 To maintain and distribute any software libraries, implementor's
kits, or other materials whose authors want them to be generally
available without cost to the Common Lisp community. If the resources
of the organization are sufficient, the organization may help to fund
the production of new materials (programs, documentation, training
materials, etc.) whose existence would be of benefit to the Common Lisp
community as a whole.
2.5 To disseminate news of general interest to the Common Lisp
community, normally by electronic mail, but with hardcopy service
available for those members who need this.
2.6 To organize meetings whenever these are necessary. The organization
may pay the travel expenses of officers and members of the executive
council and technical committee to attend these meetings.
In order to perform these functions, the organization will require a
certain amount of technically competent clerical help. It will also
need good access to the Arpanet and CSnet, a substantial amount of
online storage for records, code, and documents, and some facilities for
producing hardcopy documents and mag tapes. There is probably not
enough clerical and administrative work at present to keep a full-time
office staff busy; on the other hand, I can state from personal
experience that to do this administrative work right requires more time
than we can count on getting from random volunteers, especially if they
are busy Lisp wizards with projects and deadlines of their own. So, for
the near future, it seems best to have the organization contract with
someone else to provide the necessary equipment and administrative
services for a fee -- perhaps one of the universities or some company
like Lucid.
3. CLASSES OF MEMBERSHIP
3.1 Individual Members
An individual may join the association as an individual member by
payment of the annual dues. The amount of dues will be set by the
executive council, but I propose $25/year as the initial amount. The
idea is that the individual dues should be just high enough to pay for
the administrative costs of communicating with the users.
[ Would we get a higher percentage of "serious" Lisp people if the
individual dues were higher? Does it matter? On the one hand we want
to popularize the language; on the other hand, a lot of damage could be
done if the organization were flooded by people whose main interest is
how well Common Lisp runs on their Commodore 64's. Maybe the checks and
balances described below will suffice to keep the design reasonably
stable. If not, one nasty trick would be to charge a low price for people
reachable by Arpanet or CSnet, and a higher price for those reachable
only by physical mail. ]
Individual members have certain voting rights, as described below. They
receive all communications that are sent to the membership at large
(either by electronic mail or, if they so request, by physical mail).
They also may obtain libraries, implementor's kits, and any other
public-domain information maintained by the association for only the
cost of preparing and shipping the media to them. Finally, there will
occasionally be meetings of the membership (though it may be necessary
to charge an additional registration fee for these meetings to cover
expenses).
3.2 Corporate Members
Any corporation or other organization can join the association as a
corporate member by paying the annual dues. Membership by a corporation
does not necessarily imply that the corporation favors the use of Common
Lisp over other Lisp dialects or other programming languages, but merely
that the corporation favors the standardization of Common Lisp and wishes
to support that effort and to participate in it.
[ Do we allow foreign companies to join? I hope so. If possible, we
want Common Lisp to be a worldwide standard, not just a U.S. standard.
Universities and U. S. government agencies would probably not want to be
corporate members, but would just have some people join up as
individuals. ]
It is the dues of the corporate members that support the organization
and its activities, so these dues are significant. Again, it is the
executive council that sets the dues, but I believe that the initial
level should be $10,000/year for each corporate member. Assuming that
we get at least ten such members and can obtain the necessary services
at favorable rates, the organization should be on a reasonably secure
financial footing. There would presumably be some DARPA money keeping
the organization afloat at the start, and once it's running well there
might be many more than ten corporate members -- there certainly are
more than twenty companies working on Common Lisp or closely related
products.
Corporate members receive the following benefits:
* Certain special voting rights, as described below. Each corporation
will designate one person to act as its representative in such votes.
This person will receive all the rights of individual membership,
whether or not he or she is an individual member.
* Free access to the Common Lisp materials maintained by the
association, and assistance of the administrative staff in obtaining
these items.
* Official validation of any Common Lisp product they might produce for
only the cost of running the tests.
* Free use of the Validated Common Lisp trademark in advertising for
products that have been duly validated.
* The list of current corporate members will be included in some
materials released by the association, so that we can all be grateful
to those companies who have paid their fair share.
If a company that is not a corporate member of the association wants to
have an implementation validated and to use the trademark, the fee is
$11,000 per year, plus costs. This fee may be waived for any
implementation that is distributed for free or for a price that only
covers the distribution costs.
[OK, how many out there believe that your companies would join up as
corporate members under the scheme described here? How sensitive is
this decision to the amount of the dues?]
4. GOVERNANCE
[ All of this needs to be polished up. Does anyone have a copy of some
similar association's bylaws? We may as well copy some existing model
rather than reinventing the wheel. ]
The basic idea is that the organization will require the usual
complement of officers (president, vice-president, and
secretary-treasurer), along with an executive council of six [?]
members. Administrative issues and any major expenditures of the
organization's funds will be decided by majority vote of this group
(officers plus councillors). No more than two of the executive
councillors may be employed by any one company, university, or other
organization.
The officers are elected annually; the council members serve
two-year terms, with half the members being elected each year. These
officers and councilors are elected by the individual members. The
balloting will be done by electronic and physical mail, according to the
preference of each member. Prior to the election, the existing
executive council and officers will nominate at least one candidate for
each opening; any corporate member or any group of five [?] individual
members may put forth additional nominees whose names will be included
on the ballots.
Technical issues relating to the Common Lisp specification or related
specifications are decided by the seven-member Technical Committee, as
described below. The members of this committee serve two-year terms,
with half being elected each year. [The number seven is arbitrary, but
it wants to be an odd number and does NOT want to be five.] No more
than two members of the Technical Committee may be employed by any one
company, university, or other organization. Technical Committee members
may also be officers of the association, but no one may serve on both
the technical committee and the executive council at once. The
nomination and balloting procedures are the same for the technical
committee as for the executive council.
It is essential that the organization do whatever is necessary to
protect the councillors, committee members, and officers from any legal
actions that might arise in relation to their activities on behalf of
the organization. Unless this protection can be made fairly airtight,
it's going to be awfully hard to find volunteers.
5. TECHNICAL DECISIONS
We begin by accepting the language description in "Common Lisp: The
Language" by Guy L. Steele Jr., in the first edition as published by
Digital Press, as the initial authoritative language definition for
Common Lisp. The "current definition" of Common Lisp is this book, as
modified by any duly approved amendments or clarifications, until such
time as a new comprehensive document is approved. At any given time,
the association will make available to members all those documents
which, taken together, constitute the current official definition of the
language. Any validation tests approved by the association will (try
to) conform to this official language definition.
The issues to be considered by the technical committee will be
classified into four categories, as follows:
1. Proposed changes and extensions to the current official Common Lisp
definition.
2. Clarifications, where in the opinion of the the technical committee
the current definition is ambiguous, inconsistent, or clearly
unworkable.
3. Validation issues, concerning whether the validation tests properly
reflect the current language definition.
4. Related standards, not part of the Common Lisp definition itself.
The decision process is as follows:
First, the issue is raised by the technical committee and is
communicated to the membership. A recommendation may be sent out at
this time as well. All members are invited to express their views on
the issue, but the decision is made by the technical committee.
After a discussion period of at least fourteen days, the technical
committee, by majority vote, will make a decision, and the result will
be communicated to the members.
Any corporate member may challenge a decision by the technical committee
by calling for a vote of the corporate members. This challenge must
occur within two weeks of the announcement of that decision. If a
majority of the corporate members vote to veto the decision, it is set
aside. In the case of a proposed change, extension, or related
standard, the status quo prevails; in the case of a clarification or
validation issue, the decision is, in effect sent back into committee.
If a decision is not challenged within two weeks, or if it is not vetoed
by a majority of the corporate members, it is adopted.
∂21-Jan-85 2117 fateman%ucbdali@UCB-VAX Re: A proposal
Received: from UCB-VAX.ARPA by SU-AI.ARPA with TCP; 21 Jan 85 21:16:55 PST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.40)
id AA16781; Mon, 21 Jan 85 21:08:58 pst
Received: by ucbdali.ARPA (4.24/4.40)
id AA23652; Mon, 21 Jan 85 21:17:42 pst
Date: Mon, 21 Jan 85 21:17:42 pst
From: fateman%ucbdali@UCB-VAX (Richard Fateman)
Message-Id: <8501220517.AA23652@ucbdali.ARPA>
To: Fahlman@CMU-CS-C.ARPA, cl-charter@SU-AI.ARPA
Subject: Re: A proposal
Cc: ohlander@USC-ISI.ARPA, quinquevirate@SU-AI.ARPA, squires@USC-ISI.ARPA
actually, (3) seems much simpler; (2) could evolve in an orderly fashion
over a long period of time into an ANSI Standard Common Lisp committee
under the auspices of IEEE; and (1), the proposal you favor, would probably
cost $50k in legal fees just to start up. That's not even counting the
legal fees of the companies outside CL Inc. who must analyze the rules
before joining.
I think that unless CL Inc owns the copyright to GLS's book, the exercise
is totally at the mercy of Digital Press. Would D.P. sell the copyright
to CL Inc.? If so, the royalties accruing might support a small staff.
Why, after all this, is (3) not so bad? Well, look at what happened
to Lisp 1.5, and the little MIT press blue&white book describing it.
Was that so bad? Did anyone ever validate a lisp 1.5 implementation?
If DARPA wants to specify to contractors that their application deliverables
must be "Common Lisp compatible", or "Strategic-Computing Lisp compatible",
then they need not be written in a full "Validated Common Lisp", but
could (for example) be written in any subset, or any Lisp whatsoever that
by Turing-equivalence could be simulated in a CL system.
IF you continue to try for plan (1) and include this corporate thing
then the current group of interested people will quite certainly lose control
of CL to the extent that it becomes commercially important. Imagine the
vetoes from Hughes, Lockheed, Boeing, General Dynamics, GE, Aerospace, Ford,
GM, Chrysler, United Industries, Fujitsu, Mitsubishi... in addition to
the more cost-conscious of the computer vendors.
I suggest that only individuals be allowed to vote, as is the case with
IEEE standards committees.
∂22-Jan-85 0819 greek@DEC-HUDSON Problems with MAKE-HASH-TABLE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 08:19:00 PST
Date: Tue, 22 Jan 85 10:43:46 EST
From: greek@DEC-HUDSON
Subject: Problems with MAKE-HASH-TABLE
To: common-lisp@su-ai
I got a response from Dan Aronson concerning my problems with the
:REHASH-THRESHOLD argument to MAKE-HASH-TABLE. I still don't understand
it.
He said that when the threshold was an integer, then the rehash size also
had to be an integer and the table should grow when it is greater than
threshold/size percent full. Dan, did you mean threshold/rehash-size
or threshold/original-size? Don't forget, the rehash size is the number
of entries to ADD, not the new size. I think the book wants to say
that the threshold is an integer greater than zero and less than the
size after rehashing, not the rehash-size.
I still don't know what to do if the threshold is a fraction. Is that
a fraction of the original size or the rehashed size?
I can use plenty of common sense when reading the description, but it
still doesn't make any sense.
- Paul
∂22-Jan-85 1015 STEELE@TL-20A.ARPA Re: A proposal
Received: from TL-20A.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 10:13:32 PST
Received: ID <STEELE@TL-20A.ARPA.#Internet>; Tue 22 Jan 85 13:15:46-EST
Date: Tue 22 Jan 85 13:15:38-EST
From: STEELE@TL-20A.ARPA
Subject: Re: A proposal
To: Fahlman@CMU-CS-C.ARPA
cc: cl-charter@SU-AI.ARPA, quinquevirate@SU-AI.ARPA, ohlander@USC-ISI.ARPA,
squires@USC-ISI.ARPA, STEELE@TL-20A.ARPA
In-Reply-To: Message from ""Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>" of Mon 21 Jan 85 23:18:13-EST
While stability is well and good, I am also concerned that the natural
conservatism of the corporate interests may stifle necessary improvements,
particularly clarifications and resolutions of contradictions, in the
long run. I would like to suggest either of two modifications for
consideration:
(1) Corporate veto requires a two-thirds majority of corporate members.
(2) Corporate veto requires only simple majority, but the veto can be
overridden by unanimous vote of the technical committee.
I thought of (1) first, but I slightly favor (2), the point being that
that involves an extra step and therefore gives the technical committee
feedback on how corporate members feel before making the final decision.
(Perhaps the word "unanimous" should be changed to "three-quarters
majority" in (2), especially if the technical committee is larger than
ten people. Three-quarters majorities for odd numbers of people are:
6 of 7; 7 of 9; 9 of 11; 10 of 13; 12 of 15. But this is premature
fine-tuning.)
-------
∂22-Jan-85 1112 NET-ORIGIN@MIT-MC Problems with MAKE-HASH-TABLE
Received: from MIT-MC.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 11:12:33 PST
Received: by mit-eddie.Mit-chaos.Arpa id AA29565; Tue, 22 Jan 85 14:10:26 est
Received: by godot with CHAOS id AA11012; Tue, 22 Jan 85 14:05:49 est
Date: Tuesday, 22 January 1985, 14:06-EST
From: Dan Aronson <godot!Dan@AQUINAS>
Subject: Problems with MAKE-HASH-TABLE
To: mit-eddie!greek%DEC-HUDSON.ARPA@GODOT
Cc: mit-eddie!common-lisp%su-ai.ARPA@GODOT
In-Reply-To: <8501221627.AA28645@mit-eddie.Mit-chaos.Arpa>
Paul,
If you are complaining about how the definition of :REHASH-THRESHOD is
written I agree. It seems that we both understand what it means but the
description is incorrect.
--Dan Aronson
∂22-Jan-85 1203 greek@DEC-HUDSON Problems with MAKE-HASH-TABLE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 12:01:28 PST
Date: Tue, 22 Jan 85 15:03:42 EST
From: greek@DEC-HUDSON
Subject: Problems with MAKE-HASH-TABLE
To: common-lisp@su-ai
No, Dan, honest, I don't understand what the manual is saying.
I'm really asking people for clarification, really, really.
- Paul
∂23-Jan-85 0502 WHOLEY@CMU-CS-C.ARPA Make-Hash-Table
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 19:55:19 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 22 Jan 85 22:56:36-EST
Comments: This message delayed at SU-AI by error in distribution-list file
Date: Tue, 22 Jan 1985 22:56 EST
Message-ID: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA
Subject: Make-Hash-Table
(I sent a version of this message earlier today, which apparently never got
back to me or anyone else at CMU. Here's another try. I added a new paragraph
while resending.)
I propose the following clarification to the specification of how the
:rehash-threshold and :rehash-size options interact:
There are four cases:
1. :rehash-threshold is an integer and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), the rehash-threshold is scaled up by
multiplying it by the ceiling of the ratio of the new size to the
original size.
2. :rehash-threshold is an integer and :rehash-size is a float.
In this case, when a hash table is grown (by multiplying the current
hash table size by the rehash-size), the rehash-threshold is scaled
up by multiply it, too, by the rehash-size.
3. :rehash-threshold is a float and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), we just leave the rehash-threshold
alone.
4. :rehash-threshold is a float and :rehash-size is a float.
To grow, just multiply the current hash table size by the rehash-size
and again leave the rehash-threshold alone.
If :rehash-threshold is a fixnum, then the hash table is grown when the number
of entries in the table exceeds the :rehash-threshold. If :rehash-threshold is
a float, then the hash table is grown when the ratio of the number of entries
in the to the size of the table exceeds the :rehash-threshold.
This seems to be the "obvious" interpretation of the description on pages
283-284, and this is how I intended to implement hash tables for Spice Lisp. I
believe I broke the behavior sometime when I was trying to eliminate non-fixnum
arithmetic from the system while bootstrapping a new instruction set. So,
those with our code: beware. I'll fix it soon.
Oh, I noticed there's a funny typo in the index. On page 461, instead of
":rehash-threshold keyword," it says ":rehash-threshold keyboard." I wonder if
there are any others like that.
--Skef
∂23-Jan-85 0502 WHOLEY@CMU-CS-C.ARPA Make-Hash-Table
Received: from CMU-CS-C.ARPA by SU-AI.ARPA with TCP; 22 Jan 85 19:55:19 PST
Received: ID <WHOLEY@CMU-CS-C.ARPA>; Tue 22 Jan 85 22:56:36-EST
Comments: This message delayed at SU-AI by error in distribution-list file
Date: Tue, 22 Jan 1985 22:56 EST
Message-ID: <WHOLEY.12081735733.BABYL@CMU-CS-C.ARPA>
Sender: WHOLEY@CMU-CS-C.ARPA
From: Skef Wholey <Wholey@CMU-CS-C.ARPA>
To: Common-Lisp@SU-AI.ARPA, Common-Lisp-Implementation@SU-AI.ARPA
Subject: Make-Hash-Table
(I sent a version of this message earlier today, which apparently never got
back to me or anyone else at CMU. Here's another try. I added a new paragraph
while resending.)
I propose the following clarification to the specification of how the
:rehash-threshold and :rehash-size options interact:
There are four cases:
1. :rehash-threshold is an integer and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), the rehash-threshold is scaled up by
multiplying it by the ceiling of the ratio of the new size to the
original size.
2. :rehash-threshold is an integer and :rehash-size is a float.
In this case, when a hash table is grown (by multiplying the current
hash table size by the rehash-size), the rehash-threshold is scaled
up by multiply it, too, by the rehash-size.
3. :rehash-threshold is a float and :rehash-size is an integer.
In this case, when a hash table is grown (by adding rehash-size to
the current hash table size), we just leave the rehash-threshold
alone.
4. :rehash-threshold is a float and :rehash-size is a float.
To grow, just multiply the current hash table size by the rehash-size
and again leave the rehash-threshold alone.
If :rehash-threshold is a fixnum, then the hash table is grown when the number
of entries in the table exceeds the :rehash-threshold. If :rehash-threshold is
a float, then the hash table is grown when the ratio of the number of entries
in the to the size of the table exceeds the :rehash-threshold.
This seems to be the "obvious" interpretation of the description on pages
283-284, and this is how I intended to implement hash tables for Spice Lisp. I
believe I broke the behavior sometime when I was trying to eliminate non-fixnum
arithmetic from the system while bootstrapping a new instruction set. So,
those with our code: beware. I'll fix it soon.
Oh, I noticed there's a funny typo in the index. On page 461, instead of
":rehash-threshold keyword," it says ":rehash-threshold keyboard." I wonder if
there are any others like that.
--Skef
∂23-Jan-85 0743 greek@DEC-HUDSON MAKE-HASH-TABLE
Received: from DEC-HUDSON.ARPA by SU-AI.ARPA with TCP; 23 Jan 85 07:43:21 PST
Date: Wed, 23 Jan 85 10:45:43 EST
From: greek@DEC-HUDSON
Subject: MAKE-HASH-TABLE
To: common-lisp@su-ai
I think Skef's got it. That's the way I implemented it too.
- Paul